Bertrand Meyer's technology+ blog

There is currently in Kazan an exhibition of the works of the Tatar painter Baki Urmanche (1897-1990). One of his early drawings is entitled “The painter, the muse, and death” [1]:

It makes a good point. Not just about painters.

Note

[1] Художник, муза и смерть. The first word means “artist” but also, more specifically, “painter”, which Urmanche was (although he occasionally dabbled in other arts), so either translation is possible.

On how to build software, there is still much we do not know for sure; but we have also learned a few principles that can be considered firm.  By definition these are not new ideas; today’s principle, for example, is related to what agile developers know as “timeboxing”. But even if they have been published and discussed they are not universally applied or understood.

An  example is the CPU Clock principle: release at fixed frequency.

When planning for a new release of a system you can play with three parameters: functionality; quality; release time. The CPU Clock principle states that once a release time has been set you should never budge. If something has to go, it will be functionality.

At Eiffel Software we have been applying this principle systematically since shortly after we released EiffelStudio into open source in 2006. There are two releases a year, the  “Northern Spring release” on May 15 and the “Southern Spring release” on November 15 [2]. The content of each release is finalized six weeks before (April 1st, October 1st) and no delay is tolerated [3].

This scheme is a radical departure from the previous mode of operation. Of course every release had a planned delivery date, but it also had planned functionality; often, the functionality was not all ready at the appointed time, so the delivery date would shift, often by many months. No doubt the release plan was thought realistic at the time the team devised it, but it is a natural human tendency to promise too much and hope for the best. Delays came not so much from major obstacles, as features would get dropped if found too hard to include, but from functionality which the team believed to be “almost there” as the release date approached; a week passed, then a month, then maybe a half-year or more.

The better technique, as we have learned (no doubt many others have too) is to make release time the non-negotiable target. As with the clock cycle of a CPU in a modern computer, the sequence of release deadlines is the heartbeat to which everything else in the process must synchronize. The scale is different from that of a computer by a few orders of magnitude (months rather than pico- or nanoseconds), but the principle is the same.

The scheme requires a strict rule that whatever is not ready in time will not make it into the release. Indeed it has occurred a few times that some scheduled functionality had to be dropped, or at least moved to the next release. But now — with two and a half years of experience — comes the remarkable lesson: this case, dropping a planned feature because it is not ready at the appointed time, happens only exceptionally. It is not hard to analyze the reasons:

• Developers work better. It is not pleasant, for a developer who has devoted considerable effort to a new mechanism, to see that it does not make it to the product. Knowing that the deadline is coming, and that it is for real, is a powerful incentive to finish the work.
• Everyone, managers and developers, learns to be realistic. Managers will not set impossible goals; developers will not commit to impossible implementations.

Traditionally, some software projects have always had to treat delivery time as the number one goal. If you had to adapt an automatic teller machine network to the introduction of the euro, there was not much other choice than to be ready on January 1, 2002, and preferably a little before that. But many projects have a more lackadaisical attitude. They would fare better by adhering to the CPU Clock principle.

In describing it I have left a question open. Functionality should yield to  release punctuality, but we saw that there is a third parameter:  quality. What about it? Should we be ready to sacrifice it as well? I will not address the question furtherfor the moment, if only because this may be a good topic for reader comments before I come back to it in a future post.

The CPU clock principle addresses release times: the times when new versions of the product are made available to its users. It does not necessarily apply to internal milestones of the development team. Timeboxing, a related idea made popular by agile methods, is about such internal, intermediate steps; the typical iteration period of timeboxing is a f ew weeks. While fixed deadlines and a fixed frequency may be useful for such short internal iterations, the case for timeboxing is less compelling, especially for a large project where the various components may evolve along different timelines.

Because the CPU Clock principle governs the global scheduling of a product development, the scale is different. I cited above the 6-month periodicity of EiffelStudio development; although each project will define its own period, it makes no sense to go below one month for any significant software effort.

How universal is the principle? Only two exceptions come to mind: very small projects, and the initial phase of a project, when the development is taking shape and it is too early to define the ideal release scheme. Outside of these two cases, I see the CPU Clock principle, on the basis of our experience and of discussions with many developers and project leaders, as the only sustainable model for healthy software projects.

Notes

[1] EiffelStudio open-source development page, see here.

[2] Formerly known as the “Spring release” and “Fall release” until someone complained of hemisphere bias.

[3] Actually some last-minute technical problems have occasionally caused short delays in the actual delivery, without affecting the overall cycle. We have taken measures to ensure that these do not occur again.

I am jealous of Emmanuel (Manu) Stapf who blogged about this before I had the time to; but I can at least refer you to his entry [1].

The idea actually comes from Martin Nordio, who as part of his thesis work formalized the exception semantics of both Eiffel and Java. In the process he came across some (shall we say) interesting properties of Java, and got into the habit of asking people first if they know Java well, and then if they can predict the results of some simple programs.

So, do you think you know Java? If so, please take the test, and wait for the answer next week in Manu’s blog.

Reference

[1] Emmanuel Stapf: “And people are still using Java?” blog entry.