One of the enduring issues in software development is that of metaphor: that is, what existing, known process will we use as a way to explain development. We have taken our current metaphor from the Building Trades. We talk of “architecting” software systems, “building” releases, to mention just two. Our choice of metaphor is important as it will limit our thinking. Using several metaphors, deployed at different times to see different aspects of the development process will reveal more than any single metaphor, as Gareth Morgan showed for organizations in Images of Organizations. Software development has consistently and almost solely used Construction metaphors for many years.
I think that using Construction as a metaphor has run its course of usefulness. It’s time to get another one.
Construction is limited because what we do is not simply create structures. We like to think that it is simply about writing software, in the same way that a structural engineer wants to think that it is simply about creating a good dam. Neither is correct, or at least only correct as far as his job goes. The actual software development process is a process of change and needs a bigger metaphor to clue us into the variety of problems that come up.
Urban Development and Renewal may work. Like software, it involves many technical decisions enclosed by political ones. Chicago’s public housing towers were well engineered (at least, most of them) but they failed at the overall goal of raising the poverty-stricken. The failure of them as housing is appalling in retrospect. Chicago tore down slums to put up projects, massive high-rises for people who had never lived in such an environment. These modernist buildings aren’t that great to live in, community-wise, even for the wealthy. For the poor, they made worse what was already a bad situation. For the political powers, it had several advantages.
(American government-subsidized housing is fairly different than UK and continental models, although one can argue that they are currently working as a ghetto for Muslim immigrants.)
This miles-long stretch of public housing towers centralized the poor and, let’s admit it, the non-white in one area. The massive green lawns, a nightmare for residents because they are indefensible stretches of no-man’s land, provide a high-modernist order to the poor’s housing. The interesting areas are always on the edge of the projects where buildings are used for a variety of unintended purposes.
Software development is much like this. We erect massive monuments to our own power (large systems), frequently ripping out old, working systems just as the Chicago powers ripped out the old, semi-working slums, only to put in something that works worse. Like the architects of the projects, our software architects create systems that look good to them but that are usually fairly unliveable.
Perhaps Urban Development is a good metaphor for us to start using. It gives us lots of cautionary tales.
Of course, if you read Stuart Brand’s How Buildings Learn — or Christopher Alexander’s better works — you might think that Architecture, with its inability to make a liveable space for real humans, makes a wonderful metaphor for systems development.
Image Credit: GPN-2000-000354 Analog Computing Machine in Fuel Systems Building Lewis Flight Propulsion Lab (NASA)