Software Development, Plainly: Innovation

Do we really need architecture as a metaphor for software development? Of course there are examples to be drawn from the field of architecture, which can say meaningful things about software development. But that is true of many fields. So why limit ourselves to architecture? And why insist on calling it “software architecture”, if there isn’t that much in architecture that helps to explain what “software architecture” is supposed to be about?

And why isn’t “software development” considered as descriptive enough? To me, “development” conveys a lot. By now, it is widely agreed upon that software development is best conducted in an iterative, incremental fashion. And “development” indicates something that gradually takes form, something iterative, alternating between invention, creation, assessing, adapting. Something evolutionary.

The naïve image of architecture misses entirely the stage that precedes the drawing of plans – the stage where the building is invented. The creations of architects are big things. Even if they are working on a small house, the end result is usually bigger than their offices, and building the actual house usually takes a long time, and costs a lot of money. So in figuring out what to build, they need to work in media that is cheaper and quicker but still informs them about whether their ideas will work.

So they draw sketches, they build models in different scales, they walk around the site and imagine what the building will be like, and so on. They’ll do anything that is quick and cheap but helps them in developing their ideas. For instance, in an article in the magazine published by Louisiana Museum of Modern Art, an architect who worked with Jørn Utzon, who is most famous for the Sydney Opera House, tells of how they used, among other things, an array of empty bottles to find out the proper distance of the columns when designing the Kuwait National Assembly.¹

My point is this: The architect doesn’t draw plans, but invents buildings; it isn’t the skill in drawing plans that makes the architect, but the skill in coming up with good ideas for buildings. I think it is quite striking that the aspect of innovation almost never is mentioned in the context of “software architecture.” It is as if, for any given software project, there would be but one “right” solution, and the job is finding it, by “mining” the context. Then: conceptualize, build, ship.

Software development is, in part, about mining the context, but it is also to a very large extent about invention, about being creative in coming up with solutions to problems. But beyond solving the problems mined from the context, the creative software developer also finds new potential features made possible by the code accumulated so far in the project. In that he or she is a peer among other software developers, not simply a “builder” executing the plan of an “architect.”

¹ I wrote more about this in the post “Johan Fogh om Jørn Utzon” (in Swedish).