A Metaphor for Software
I’ve recently been reading Code Complete by Steve McConnell (review of the book to follow when I’ve finished). In one of the early chapters of the book, McConnell discusses software metaphors and their importance. I won’t get into too much detail here, and I’m operating off the top of my head from what I read a couple of weeks ago, but he lists various metaphors from least useful/appropriate to most useful/appropriate. As I recall, the least useful was “writing” code, in the sense that one sits down and composes a letter, and the most useful was that of building construction.
That is to say, a good metaphor for the process of software engineering is the process of, well, building engineering. There is a good amount of up-front planning (since this was written in 2004, before agile processes gained the following that they have today, this seems like a reasonable thing to write), a sense of architecture and framing, scheduling issues representable by Gantt charts, a quality process, etc. I think that this is certainly a good metaphor. In this chapter, he also encourages the reader to invent his own metaphors as this ongoing collective exercise will be useful for describing the software engineering process in the future.
I’ve been letting that percolate in my head the last couple of weeks, thinking about the rise of the aforementioned agile processes between the writing of the book and now, as well as the nature of software itself. What I’ve arrived at for my own metaphor is a work in progress, so please bear with me and feel free to contribute your own thoughts, as I would enjoy working through this as an exercise to improve the way I think about development.
The metaphor that I’m considering is one in which the software is an amorphous blob of children in a school system, the software engineers are teachers, the software architect is, perhaps a principal, the project managers are deans or the equivalent, and marketing people are the political school board types that set the curriculum. The customer stakeholders in this scenario are the parents of the children, let’s say, and to a lesser extent, society at large.
The basic idea here is that software is a student of sorts. When we develop, we start with software that does (knows, in the metaphor parlance) nothing. We then take a set of requirements set by some mixture of marketing people and customers (school administrators and parents, driving the administrators politically) and set about ‘teaching’ the software to do what we want it to. At first, the software (student) is lovably inept, but as we teach it how to satisfy more and more of the requirements, it begins to resemble the end product that we desire (a student or group of students ready to function in society as productive adults, able to perform the tasks that we have taught).
I like this metaphor for a few reasons. Number one, it seems to describe agile methodology better. The curriculum/requirements may constantly be refined and changed throughout the education/development process. Secondly, we really do teach our applications to do things — much more so than we build them to exist. With the construction metaphor, our code-house doesn’t do anything — it just exists, and it exists more as we build it. With the education metaphor, our code gets better at performing the tasks that it is slated to perform. Third, I think this naturally captures the politics of the stakeholders in the software engineering process much better than the construction metaphor, whose only politics exist between the primary agent of construction and the purchaser — the software company and its customer, respectively. I suppose you could laboriously describe a scenario in which the construction company has a sales office that promises things to the purchaser of the building and the sub-contractors balk, but that’s fairly limited. In the case of the education system, overbearing parents or administrators with agendas frequently clash with the teachers over the best way to educate the students — over what the software should know/do in the end.
So, what about Agile vs Waterfall? Well, admittedly, that gets a bit more abstract, but the construction metaphor is always, almost by definition, waterfall. Not very many houses start as fully functional, small studio apartments and grow upwards, downwards and outwards from there. But children being educated start with a core, accurate set of lessons that expand as time goes by. Throughout the course of this process, they behave like increasingly sophisticated mini-adults.
As I write this, it occurs to me that perhaps the iconic metaphor is well-suited for waterfall shops and this one for agile ones. The education metaphor becomes a bit labored with waterfall, though certainly not untenable. I suppose a waterfall education would be like a schoolboard saying, “all right, all children entering kindergarten now have their curriculum set through 2024, so nothing else will be added between now and then, though we will leave an hour per week so that they may learn about whatever gets invented between now and then.” (Hey, learning about things going on now is more of a college kind of thing anyway.) But then, perhaps the metaphor is appropriate, as I think it’s pretty well agreed upon that a pure waterfall approach has a natural tendency to result in software that is obsolete the day it leaves the shop. Either that, or the waterfall nature is not strictly practiced — the school system relents and decides that perhaps current events are reasonable for the curriculum, so long as they’re particularly important — the breakup of the USSR makes the cut, but the latest correctional struggles of Lindsay Lohan do not.
I will come back to expand on this post in the future as I refine the metaphor, and am happy to discuss the issue with anyone who may have comments.