For as long as I’ve been in this business, I’ve heard a lot of manager, project managers, architects and other non-coders compare software development to construction. In this metaphor the architect creates the design and hands it over to the contractor, who does the work. In this metaphor the creative parts ends with the architect handing over the design to the builders. Now doesn’t that sound like a software development project to you?
City planning and blueprints
There is a lot of terminology in software development originating from this metaphor. Never heard an architect talking about the systems landscape, or that architecture is like city planning? And where did you think the term architecture itself originates from? Or the fact that we are building software? And aren’t we still discussing software construction and layered architectures? Did you know that in SAP projects people still refer to the design as a blueprint.
At first sight this metaphor makes sense. However, what has worried me about this metaphor over the past twenty years is that the creative part ends after the design is delivered by the architect. No pretty sight for developers eyes. In construction, this seems to be true. It’s the main reason construction is done by low educated workers against equally low wages.
Ignoring creativity
Converting this metaphor to software development, as a consequence, when the software architecture and design is done well, coding could be done elsewhere in the world by low educated people much cheaper than we are. This is where I highly dislike the construction metaphor. It considers coding as non-creative and repetitive work. It simply ignores creativity.
Moreover, it also surpasses the fact that, as agile projects prove, the quality of software improves at high pace when there’s regular contact with the customer during development, much like the idea that during construction of your new house you regularly visit the construction site and pass comments to the contractor.
So this is where it all comes down to. The idea that an architect sits at his desk and actually design the software at his desk, after having consulted the customer. This is were creativity is ends, and building the software begins, according to plan.
From this crippled metaphor traditional methodologists have fantasized the living daylights out of us poor developers. We were made to believe that software development is a craft rather than creative work. If the architecture is set out correct and presented nicely, building the software is low skilled, repetitive work. And hence, it can easily be outsourced, offshored and done by low educated third world software developers.
So if all this would be true, and construction is a good metaphor for software development, why is it not all projects are delivered successfully, on-time, and on-budget?
Watching plumbers
I’ll tell you why. Last week my new house was delivered by my contractor. Since then, all of the sudden, I’m surrounded with lots of activity in and around the house. This activity falls in the fore mentioned category of low skilled, non-creative work. The house is crowded with plumbers, carpenters, friends with DIY capacities, gardeners. Some of them build closets, others construct my bathroom, whilst others lay floors or grass. And me? I’m constructing a attic in the garage with a friend.
When I was watching our plumbers reconstruct my bathroom, it occurred to me. After over twenty years in this business, I finally saw the light. Having opposed the house building metaphor for software development for so long, it’s time to see things through. Time for a little re-construction.
The plumbers in my bathroom, both in their early fifties actually quite enjoy their work. As I enjoyed constructing an attic in my garage. They were singing and making (lousy) jokes. Why is it, I wondered, that these middle aged, low educated construction workers whistle and make jokes during this work, that they’ve probably been doing since they left high school. Why?
I’ll tell you. It’s creative work. They try to make the water taps fit in the wall of my bathroom. It’s a puzzle. Drill bits and holes in my wall, fitting the taps again. It’s even fun watching. It’s actually quite like I would address software development. Build it, try it out, test it, and possibly refactor the code. The plumbers actually work quite agile. During the process they ask me where I want the tap, where the shower should be, or they propose suggestions on the tiling plan. Although the bathroom isn’t finished yet, I’m quite sure it will work out fine.
Applying patterns
And moreover, the plumbers work is bound by the bathroom architecture we’ve laid out, and even more by patterns, just like developing software is bound by software architecture and by design patterns. The plumbers know how high the shower regularly sits on the wall, how many centimeters they will have to drill in the wall to make the tap fit, just like I will use some implementation of a model-view-controller to implement the user interface, and domain driven design to construct the domain layer of my application.
And you know what, to round up my argument, they make errors too, just like we software developers do. And yes, they make repairs, like we do. It’s a bit like refactoring. They try to create a solution, but if it doesn’t work, they’ll fix it, and try something else. Just like I would refactor my code, if it doesn’t perform.
But most of all, there’s one simple thing that binds us software developers to gardeners, plumbers, and carpenters. So much for the construction metaphor. No doubt about it. Just like software construction. It’s creative work. Don’t let anybody ever tell you otherwise.