Author Archives: Jere

Imagine software development as building a bridge. We have architects which design the bridge, materials used for construction, and construction workers who put it all together according to the architect’s plans.

In the bridge building world, architects hand their plans off to the construction workers, who then put the bridge together. In this world, changes to the design become more and more expensive as time goes on – it’s what we read about in computer science classes about traditional waterfall design. And it made intuitive sense, since we could see how it would be much harder to change a bridge design once construction got started.

However, there is a critical flaw in this analogy. Software costs nothing to build. If I have 50,000 lines of code I can compile an executable in a few seconds. I can make a 2 line change to that codebase, and in just a few more seconds, I can have a new executable. I can make a 10,000 line change to that codebase, and the cost of compiling an executable is still just a few seconds.

So if we want to truly understand our bridge building analogy, we have to imagine a world where I could have a bunch of construction workers put up an entire bridge in just a few seconds. Tearing down the bridge would also be nearly instantaneous. And I would have not material costs for the bridge, just as compiling an executable wouldn’t cause wear on my computer’s memory, or my hard drive, or my CPU.

In this wonderful new world of instantaneous construction, how would this effect the role of the architect? Well, instead of using scale models to get a feel for what the design is going to look like, I’d just whip up a new bridge every time an idea struck me. Instead of trying to precisely calculate how the bridge would react to its environment (weather, traffic, etc), I’d simply build the bridge I was imagining and test it empirically.

Now, when it comes to tests, there are also several alternatives. I could manually test it – getting in bigger and bigger vehicles and driving them over the bridge until it broke. Or, if I was really smart, I’d have a robot army of automated testers, who would drive over my bridge thousands upon thousands of times in exactly the same way. Every time I decided to put up a new bridge, I’d just click the “go” button on my robot army, and they’d do their job.

This isn’t to say that designing a bridge would become a trivial process. In fact, the big issue with software is that *everything* is design, and these designs are terribly complex. If we have 30 architects working on designing the same bridge, we need to be able to manage communication within the team. But unless we can adjust our perception of what “building” and “designing” software is all about, we fall victim to the limits of our imagination, and focus on the wrong problems.

Boy, it doesn’t take much to keep me up till 2 in the morning. Argh.

Well, it looks like I’ve got most of everything up and running, but I’ll need to spend some more time converting toby’s site over to this new host.