Construction Metaphors

I know a lot of computer programmers hate construction metaphors and analogies. I think they fear that any comparison to physical labor demeans the intellectual requirements of building computer systems. It is too bad, because there is an awful lot to learn from watching other people toil in mammoth projects.

Construction sites aren’t just exclusively general laborers, there are usually a host of other complex jobs and professions. Skyscrapers, for instance, require architects, drafters, engineers, inspectors, project managers, electricians, plumbers and a host of specialty jobs like elevator installation or crane operation.

The same is true for medium or large software projects, you also get a large congregation of divergent professions and experience. Learning how all of these different perspectives and agendas can work together effectively is something urgently required by software projects. Too often software professionals get focused on the code -- the cement of the project -- only to miss the other necessary elements to achieve success. But a building isn’t functional until all of the other pieces are in place.

Even programmers tend to specialize in their work. It often takes GUI specialists, database admins, algorithmic gurus and system programmers just to get the core of the system going. Well-balanced system development also frequently includes domain experts, graphic designers, writers, editors and testers, not to mention the system admins and all of the support personnel (even occasionally lawyers and sales people). And one should never forget the necessity of having a good project manager around to coordinate and then pull it all together.

Technology and libraries have improved significantly since I started, but if anything, that has driven the expectation of the users towards bigger, more complex systems. Gone are the days of some guy hacking in a closet, then just installing it on a PC or two. If a computer system is really going to solve real problems (and not just add to them), it needs to integrate with the existing environment in the most seamless way possible. Dozens of little vertically-isolated systems are just adding to the problem.

This leads us to the most significant aspect of comparisons to construction: scale. Most people can build a toolbox out of wood, many can even build sheds for their backyard. These are great skills but they don’t easily transcend to larger projects such as building a house.

And being an expert in house building, doesn’t necessarily qualify someone to build an apartment building, or even to play in the big leagues with a skyscraper. They’re all construction, but each requires its own set of skills and experience. As the projects get larger, the underlying issues change, and the way people have to work together changes as well.

Failure to see this in programming has lead to a great number of colossal disasters. I’ve been on, or followed several great software projects lead by backyard enthusiasts or house-building experts who have leaped haphazardly over to trying to whip out skyscrapers with the same tools and style. Building a nice little app for a PC is an accomplishment, but because of scale, it is easier to get away with bad practices that would cripple the development of a major, integrated system. As the projects grow, the complexities grow exponentially and simple problems that would be barely noticed in a small project open up huge fatal cracks in a massive one. You might just wing it for a small shed -- fixing the problems as you go -- but that would be an insane approach to building a skyscraper.

Scale is one of those classic issues that many inexperienced programmers dismiss too quickly. I once saw a multi-million dollar system fail spectacularly, not because it wouldn’t run, but primarily because its performance was so poor that it could only handle a fraction of the number of users that would make it profitable. Just existing was not enough to claim success. That was a classic example of experienced house-builders mis-gauging the differences in size, technology and project organization. They built a pretty working system, but they missed the real criteria for success.

Construction isn’t just about digging ditches or spending all day hammering or even driving around big machines. It’s the act of manipulating materials in complex ways that breath life into something tangible. It isn’t that far removed from software. Despite all of the myths, we ultimately deliver something physical, even if we can’t see the bits on the disk, or in memory. Not unlike buildings, the users move into their software, and eventually help to change it, or morph it into an environment that is more suitable to their actions. And a poorly built software system is as unpleasant as a badly designed building. It may function, but nobody likes spending time there.

Building is building; it's the medium that changes. It doesn’t really matter if the work is more intellectually oriented or more physically oriented, the underlying issues are the same. Software may be seen as a more malleable resource, and it may seem like we have more options, but we’ve certainly learned that once a large code base comes into existence it is no easier to change than a tower of concrete and steel. I think its time for us to to look outside of our own myopic culture and start learning for the experiences of others. Construction has a long and mostly successful history, we do not. We can learn a lot from how they get their mightily works accomplished.