How to produce Good Software, Part 2

In part 1, I listed the main things that I plan to write about in this series. In this part, I thought I'd present a little bit of my software writing background to provide some context for future parts.

Over the years, I've written quite a lot of code, most of which has been systems-level software targeted at the developer community. Here's a list of the main products I've been involved with, starting with the first software product I wrote:

• Compuclinic: medical analysis
• COMAL Compiler: a compiler for the COMAL language
• Pascal Environment: interactive Pascal system
• ObjectSystems: C++ toolkit for systems programmers
• STL<Toolkit>, portable C++ collections library
• Systems<Toolkit>: portable C++ systems library
• JGL: Java collections library
• Voyager: Multi-protocol Java object request broker
• Electric XML: Toolkit for parsing and manipulating XML
• Glue: Web services platform for Java developers
• Gaia: Grid services platform

Compuclinic and the COMAL Compiler were written while I was at the University of Southampton, England, and helped pay for my early addiction to Synthesizers and Drum Machines. The interactive Pascal system was written at the University of Texas at Dallas while I was earning my Masters Degree. The C++ toolkits, JGL and Voyager were written while I was CTO of ObjectSpace, and are now owned by Recursion Software. The Electric XML, Glue and Gaia products were written while I was CTO of The Mind Electric and are now owned by webMethods.

In general, these products received favorable reviews, were well received by the developer community, and some of them (like JGL and Voyager) won several awards. The development of the products had several common characteristics that I will write about in detail in future parts of this series. In the meantime, here are some of the highlights:

• Small teams, ranging from 1 to 10 people
• Top-notch developers
• Highly iterative development cycle
• High quality code and documentation
• Small, compact code
• Easy to use
• First versions were available as beta code quite early in the development cycle

In the next part of this series, I'll describe how each of these products was conceived and initially prototyped. If there are particular aspects you'd like me to cover, please let me know.

Comments

[Simon]

I'd like to hear about some of the conventions you used in your teams of 1 - 10 people. e.g. did you use Test First approach, did you employ "bug jail" for developers, how did you iterative process work?

[Graham Glass]

Thanks for ideas Simon, I'll definitely cover the things you suggested!

[Christopher Baus]

Graham,

A lot of your products were released "free for non-commercial use." I've been debating back and forth about licensing on a product I've been working on. I'm curious what your current thoughts on this are.

Part of me wants to drink the kool-aid and go Open Source, yet another says stay strictly commercial. Then I consider the compromise that you use on JGL and Voyager.

Maybe it isn't a bad model for somebody starting out that wants to get some publicity, while keeping their options open.

[Paul Holser]

Hi Graham...

I'm interested in hearing about difficulties you encountered, and how you dealt with them; and in your stance on developer testing/TDD.

Some "rock star" programmers that I've encountered aren't much interested in the safety net that the JUnit-style tests build; they say it slows them down or doesn't add value. I tend to think that if a class or collaboration of classes is worth writing, it's worth proving that it works with automated tests...