As humans we learn by analogy, metaphor and simile, adding new knowledge by initially relating the new to our existing understanding of the world. When we try to explain the software development process to the initiated (translation business stake holders), we use all kinds of similes to help them understand the process. The problem with similes is that they argue that something is like something else and many times people confuse the similes with metaphor, thinking that one thing is another. Not only do people confuse simile with metaphor, but many of the similes we use in explaining software development are not appropriate because they can cause more harm than good and they are not very accurate in their explanation.
Take, for example, the simile that software development is like building a car. I am not sure where this came from, but coding is not at all like an assembly line. There are times where there are tasks that are like an assembly line – on my current project we are staging a great deal of data and this is very much like an assembly line. As such we are constantly working to improve the “assembly line” process were are using to create the staging tables. We have been able to reduce the time significantly as a result. Nevertheless, most coding activities revolve around creating something that previously did not exist. These are “one offs” not simply finding a better way to make the same widget. A lot of lean and Kanban take their cue from Toyota manufacturing process. While lean and Kanban have their place in creating better software, we have to be wary of confusing making cars with making software.
Another worn out example is that software development is like construction – building a house, a bridge, a road, etc. About the only thing that the two have in common is that they are both about building something. Houses, roads and bridges have to have a great deal of upfront planning our you will end up with some kind of Frankenhouse. The tenants of construction have changed very little over the years (though the materials may have changed) and are reasonably predictable (at least for smaller scale projects). Software development and software architecture are not as predictable and big upfront design has been shown to not work well for software development. Software development, because it can be refactored at any time, does not contain the inherent rigidity that construction does. Software development does not fail because we did not have the right “blueprints”. Software development fails because the “blueprints” were followed precisely and there wasn’t the framework created to allow for appropriately (and easily) changing the architecture as more is learned.
So what is the proper simile? My inclination is that we do our best to teach our business partners and the uninitiated that software development is a thing unto itself. It requires creativity, courage and flexibility. Many times the problems we solve are familiar yet novel. Until we can get people to wrap their heads around this concept, I like to use the analogy of making a movie. We have scripts and broad outlines, but the success of the final product involves the close collaboration of producers (business), directors (managers) and actors (developers, team members). There needs to be flexibility and creativity infused throughout the process as script changes, set changes, dialog improvisation, etc. prevent us from the rigidity of the construction industry approach.
What similes work for you? I would love to hear how you explain the process of creating software to your teams.