|Developer Diary · You Heard It Here First · 24 December 2003|
|Software Construction Strategy|
Two approaches to software construction might be called "evolutionary" and "grand design". In grand design the developer plans the complete project up front and does it all at once. In an evolutionary strategy the developer writes a smaller, complete version of the program first and then progressively adds to it. Both methods have their advantages.
Buildings are always done in grand design mode. You cannot change the building once it is built. Simple echanical devices, on the other hand, are often done using the evolutionary method--the core functionality is completed first and then more functionality is added later. The most sophisticated devices, though, tend to use grand design. This trend seems to be echoed in software: easy programs are built in an evolutionary way, but complex interlocking systems are designed and implemented in one step.
There is no question that doing everything at once has advantage of speed, but the hazard is that if the design is flawed the program has to be gutted and re-written. Evolutionary programs have the defect that their parts are often inconsistent with one another and they tend to have a lot of redundant code. The advantage of evolutionary programs is that you have a demonstrable result sooner and you have a working program to fall back on if the more complex parts of the program turn out to be impossible.
Personally I tend to prefer the grand design approach in most cases. In the long run it is usually more beneficial to have a program that hangs together well and has a unified shape to it. Projects done piecemeal have a way of never working quite right because the parts were not made together. Making a grand design is only advisable, however, when the architect has experience with the planned mechanisms. The evolutionary method recommends itself when something new is attempted because it is often not until a (semi-)working program is achieved that the toughest problems become apparent.
Design patterns are a good idea to get around the limitations of the evolutionary strategy. By learning abstract designs that have widespread applicability the architect can impose logical frameworks on a system even if it is being built piece by piece. Building architects do the same thing: they rely on books of known successful designs that can be applied to any building. The Hillside group maintains a good web resource page on design patterns.
|return to John Chamberlain's home · diary index|
|Developer Diary · email@example.com · bio · Revised 24 December 2003 · Pure Content|