Code as Design

When I first read it a number of years ago, I immediately found Jack Reeves’ article “What Is Software Design?” useful, intelligent and correct.

In the article, Reeves presents his arguments for why the source code is the artefact that constitutes the ultimate design of software. Apparently, this article resurfaced with the publishing of Robert C Martin’s book on Agile Software Development, after having led a quiet life in hibernation since its first publication in 1992. It is now often referenced in the agile community.

Why is this important? It is because our perception of what source code is influences our perception of what programming is. If the source code is the design, then programming is designing. If programming is designing, it becomes natural not to accept the opinion that programming should be like factory work. Of course, people who insist that other people’s work should be more factory-like will continue to insist on this until the end of time, but at least knowing there’s a solid argument saying that they’re wrong makes you feel good.

Sadly, outside the circle of agile aficionados, few attitudes seems to have changed. When I talk to people from mainstream organizations that live far from the current agile trends, the word “design” is still associated with the creation of UML diagrams, and the task of “design” is sometimes thought best performed by seasoned specialists. This of course, will be followed by mechanical implementation of said design by monkeys with keyboards.

This is truly a sad example of how easily we settle into inefficient and creativity-strangling stovepipes. A programmer without the mandate to design will either have to fail or break the rules. Luckily, many choose to break the rules, but this has the side effect of creating completely unneeded psychological stress. We all deserve to be able to do our best without having to bend stupid rules. Wouldn’t that be a great world to live in?

If you have not already read the article, do so now.