How To Build Damn Good Software

Share the article!

Graham Glass (Mind Electric fame) and John Wiegand and Erich Gamma (both of Eclipse fame) have graciously provided us with a few morsels of wisdom on how to build good (a gross understatement) software.

Graham Glass writes in his continuing series of “How to Produce Good Software”:

In general, itxe2x80x99s a good idea to have an up-front game plan for product releases. Here is a list of the constraints and assumptions that we used when formulating such a plan:

  • One year or less from the initial prototype to the 1.0 launch.
  • At least three beta releases before 1.0.
  • At least two point releases between major releases.
  • One year or less between major releases.
  • Features arenxe2x80x99t included in a release until theyxe2x80x99re very simple to use.
  • In tradeoff situations, ease of use and quality win over feature count.
  • Useful subsets of standards are OK in the short term, but should be fully implemented in the longer term.
  • Listen to users more than to analysts when selecting features.
  • There will always be a patch release 1-2 weeks after an official release.
  • Point releases should be 100% API compatible and easy to upgrade to.
  • Major releases can occasionally break APIs, but this is to be avoided.
  • On-the-wire compatibility is even more important than API compatibility.

John Wiegand and Erich Gamma presented a talk in Eclipse Con 2005, “The Eclipse Way: Processes that Adapt”. Ed Burnette has gractiously created notes from that presentation:

  • Milestones First –
    We use a 6 week cycle. Each milestone is a mini dev cycle. plan/execute/test/retrospective. Milestones reduce stress.
  • t

  • Continuous Integration -
    Fully automated build process and tests.
  • Always Beta –
    Each build is a release candidate; we expect it to work.
  • t

  • Community Involvement – Community needs to know what is going on to participate. Requires transparency.
  • Continuous Testing – We have over 20,000 JUnit tests, tightly integrated into the build process.
  • Endgame – A convergence process is applied before release.
  • Decompression – Allow recovery time from the release. Freedom to explore new stuff, retrospective of the last cycle (achievements, failures, processes, cross-team collaboration).
  • Planning – Establish themes for the next release that put the big picture in place.
  • Risk Assessment –
    Address high risk items and items with many dependencies early. Maintain the schedule by dropping items if necessary. Sandbox or serialize high risk items to reduce risk to other items.
  • Collective Ownership
  • Preserve Architectural Integrity –
    Deliver on time, every time, but must preserve architectural integrity. Deliver quality with continuity.
  • APIs First – When deifining a new API, there must be at least one client involved, preferably more.

    The release cycle: 12-16 months
    - milestones – 9 months
    - endgame – 1-2 months
    - decompression – 1 month


The team makes the process work. The team defines and evolves the process. There must be shared responsibility and full buy-in to make things happen.


For more detailed notes, consult Ed Burnette’s piece. I’m of course still on the lookout for the original presentation.

The context of these projects are quite different from the typical software project. Not every development effort has the same stringent API requirements as these two projects. However, if you are in a team involved in developing common functionality then your interaction with your community of users becomes critically important. It takes more than banging out useful functionality, you have to provide transparency and get your community involved. These two projects provide strong emphasis on the both the APIs and the Release. That is because not only do they help keep their teams synchronized, they also provide critical customer facing artifacts. APIs and releases are the user interfaces you provide to your customers.

Controlling software complexity all boils down to managing dependencies. The constructs that we have at our disposal are APIs and Configuration Management. Manage those well and you would have progressed one step further in writing damn good software. It’s just sad that I’ve seen too many projects that have paid nothing but lip service to these two aspects.


Share the article!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>