Gordon on CS Education: I sometimes say, only half joking, that the best training for a wannabe programmer is to go work on a construction site.  [...] you'll learn a lot about how to build things. [...]There's nothing magic about computers.  They're just machines.

Well, even though I fully agree with your statements regarding education, I definitely disagree with the sentences quoted above. In my opinion, building anything apart from computer programs if very different from building software. (By the way, there's also recently been a great article on this topic, titled "Beware the Engineering Metaphor" in Communications of the ACM, May 2002, page 27 to 29 by Wei-Lung Wang.)

The problem is that some people tend to see software design and development as an engineer's work even though it really isn't: "Engineering is the work of applying scientific and mathematical principles to practical ends." Real engineers have the clear advantage of a having to work within the boundaries of the laws of nature. When building a bridge or a house, you basically know the formulas to calculate if it's going to be stable or not. When building something out of concrete, you tend to have clear responsibilities: I don't know if the Golden Gate Bridge's architect discussed his ideas with the bricklayers. However, I also don't know if the Bridge's projects owners changed their mind as often as your typical IT project owners do.

In fact, I've been both architect and bricklayer when it comes to software. More often than not, when working with the bricks, I was able to give valuable feedback to the architects. After turning away from the mortar and joining the crew at the drawing board some years later, I still like to hear what's on the programmer's mind when it comes to software design. Nobody working with software has any formulas which allow you to predict an application's scalability, stability or even more interesting, a project's success or failure. We can only learn, approximate, prototype, listen to our peers, count on our experience, and hope for the best.

Anyhow, I think that people who tend to see software design the same way as building a house also make a very decent mistake: they remove flexibilty from their process. When building your house and you decide, after all walls have been put in place, to make one room larger then originally planned, the change will be quite costly. You'll have to tear down the walls and re-create them later. No matter how good your house's architect is - moving the wall will be costly. When you however decide to change an aspect of your software during the process, the cost of this change will probably be minimal. With a good up-front design, this change maybe doesn't even cost you a nickel ...

Somehow, I think that building software is quite different from building a house. And this is great! Software architects and developers aren't only engineers: we are also mathematicians and artists. Mindset does matter. We have to listen to our peers and be open for change. Also the one who doesn't want to learn, listen and prototype maybe is in the wrong business.

I guess you don't see this at an average construction site.