Design Driven Programming
Posted by Peter on April 4, 2006
We all like to talk about programming styles, but we can’t seem to agree as to what to call them. Here when I talk about design driven programming I am referring to the style in which the program is designed first, often with meticulous detail, and then coded. This contrasts sharply with the test driven style of programming (not extreme programming), where programmers create small bits of the program, test them, and then slowly put them together to form the complete program.
The Scheme and Lisp communities seem to avoid design driven development. One reason is that Scheme and Lisp make it easy to program without a finished product already in mind, and the REPL encourages programmers to design fairly independent functions which they can test and use immediately. Design driven programming also has a negative image because it is often associated with management driven programming, i.e. when your boss tells you what to do and you must follow their commands without innovation.
When I think of programming I sometimes compare it to a battle. The design driven methodology then is like a general, the lead designer, giving his troops detailed orders which they then follow out exactly. On the other hand test driven development is like the general telling his troops to go out and win the war, leaving to troops to figure things out by themselves.
If we follow this analogy a little further then we see that the biggest problem for design driven development is the unexpected. When the overall plan encounters a problem troops have to radio back to HQ for new orders, which of course takes to long, so the enemy overruns their position and the war is lost. Individual programmers, not leading such risky lives, must consult the lead designer, the design must be fixed, and then programming can resume, meaning that any design flaws lead to revisions, delays, and sometimes the need to redo parts of the overall design that were supposedly already completed. On the other hand in the test driven development unforeseen problems don’t lead to revisions or excessive delays, but it is hard to coordinate a significant number of programmers. Some soldiers go to France, some to Poland, and because they don’t coordinate their efforts the war is lost, even if they are individually all successful.
What do real general do to overcome this problem? The solution is a compromise which I call goal directed programming. A general might lay out objectives for regiments and lay down timetables, but in the field individual soldiers are given the authority to react appropriately to new situations without consulting their superiors.
The difference is probably best shown with a few examples.
|Design Driven||Go forward 100 meters, shoot 2 enemy soldiers, enter the building, guard both doors …||Write an process URL class, it should contain the following 3 functions …|
|Test Driven||Go capture the town||Create an html rendering component|