Monthly Archives: March 2005

So at work I’ve been going through the process of defining processes, and have seen many a power point and visio diagram cross my desk that just makes me want to scream. It seems that within any large bureaucracy a process is only as good as the number of pages it takes up when printed out. The number of twists and turns required to get any complex development project done is already fairly large, but when we pour on even more and more layers of paperwork and sign-off and approval, it only makes a bad situation worse.

Although lip service is given to improving processes, it seems that direct criticism of a proposed process is seen as a mark of the luddite – anyone who would dare criticize this great 50 page process power point presentation must surely not be interested in how much time you can save with a hundred extra steps! If only these process groups contained the people *doing* the damn work, and could take their knowledge and experience into account, we could actually be doing some good here.

My wife is a teacher, and it seems she’s running into the same sort of issues at her job as I am with mine. In LAUSD, instead of listening to the teachers and bringing best practices from the ground up, they have imposed “process” on the situation, and have worked to implement standards that break down the spirit and initiative of reformers within the system. The thought that one size fits all runs rampant, and because there is no effective feedback loop to the decision makers, all that happens is alienation.

I’m hoping, of course, that I can inject myself into the process of defining these processes, and provide some context to the decision makers within my company that will give them the insight necessary to build something that works, something that will be remembered years from now not as just another re-org, but as a moment of revolution. I don’t know how far I’ll get, but I’m certainly willing to try.

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.