On Scheme

Thoughts on Scheme and teaching Scheme

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.

War Programming
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
Goal Driven Proceed to hill 129, scout for enemy positions, follow the river into town … Create an html rendering component that can take html source from either a web address, a file, or a character string. It should be able to output the results to an image file or an active window. Implement html specification 1.1, without javascript.

2 Responses to “Design Driven Programming”

  1. Charlie Groves said

    I don’t know that there’s really a difference between test driven and goal driven programming. Yes there’s a difference in the way you’ve describe them, but I’ve never heard anyone advocate using test driven development with such an abstract goal in mind. You’re using the tests to ensure that the code you write converges the the desired functionality which requires that you have the desired functionality in mind.

  2. Peter said

    Yes you wouldn’t expect to find test driven development in the wild, so to speak, unless you were looking at one person teams. Let me illuminate the difference between test driven programming and goal driven programming in this way: test driven programming is like goal driven programming with only one goal: the end result. In goal directed programming one has intermediate goals that affect the construction of the program, in my example above it would be that the html input can come from several different sources, ect. If you only had the end goal in mind you would probably not develop this functionality until you found you needed it later. For example if you were working on the program by yourself, and thus using test driven programming, you might not write the html-from-string function until some later function you were writing needed it. This doesn’t work so well when Bob wrote the html component, because you can’t expect Bob to drop his current duties and make changes to his old code as soon as you need them, creating a bottleneck. This is why I am describing goal oriented programming as a kind of hybrid solution, i.e. some planning has been done in order to outline useful goals, often relating to the interface to parts of the code, but programmers still have the freedom to implement their goals in the best way they see fit, without having to stick to fixed guidelines concerning which classes and functions they will create.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: