Summary:
On a very regular basis, I find myself explaining to colleagues why it is the case that software development is so expensive and difficult to do well. I've found success by introducing three new analogies. These are software development as 1) highway construction 2) developing a space mission 3) founding a modern nation state. I discuss the pros of each of these analogies and provide a critique of the most commonly otherwise used analogies of building construction and gardening.
The Old Metaphors - Building Construction and Gardening:
David Thomas and Andrew Hunt discuss two analogies for software development in their classic book "The Pragmatic Programmer" (see Chapter 7 section 40 of 2020 edition):
On a very regular basis, I find myself explaining to colleagues why it is the case that software development is so expensive and difficult to do well. I've found success by introducing three new analogies. These are software development as 1) highway construction 2) developing a space mission 3) founding a modern nation state. I discuss the pros of each of these analogies and provide a critique of the most commonly otherwise used analogies of building construction and gardening.
The Old Metaphors - Building Construction and Gardening:
David Thomas and Andrew Hunt discuss two analogies for software development in their classic book "The Pragmatic Programmer" (see Chapter 7 section 40 of 2020 edition):
Analogy |
Good for Emphasizing |
Building Construction |
Simple, linear, repeatable, processes. |
Gardening |
Need for constant management and intervention (pests, weeding), emphasis on external conditions (no rain), things not going according to plan (hurricane took out tomato stakes). |
They make the point that the building construction metaphor is more palatable for business stakeholders because of the emphasis on structure, reliability, and predictability. However, they note that, in practice, software development is much more like gardening because of how constantly a team needs to be able to observe, manage, and respond to changing conditions.
A critique of the construction metaphor:
A critique of the gardening metaphor:
A garden metaphor is less useful if you are building something that you want to operate at scale, with, say, millions of users. Etymologically, a garden refers to an "enclosure" and my experience suggests that that most people conceive of a garden as small and most often managed by a small number of relatively low-wage workers.
Three Alternative Metaphors
Considering the points above, it's natural to consider alternatives that emphasize the complexity, specialization, and scale requirements necessary to build a modern software application that adds business value. Here are my three favorites:
A critique of the construction metaphor:
- In my experience, the most useful part of the construction metaphor is about the plumbing. Most people who live in houses don't understand how plumbing works, and they never want to have to think about it. It is clearly a specialized skill, and it helps frame the importance of getting something right because you don't want your toilet to back up, when, say, your extended family is visiting for Christmas. Business partners are also happy to not ask questions about plumbing because it's dirty and we all know it needs to get done.
- The construction metaphor can be souped up by comparing the development process to the building of a skyscraper or hospital, for example (hospital is my preference). Clearly, these require specialized expertise and, in the case of a hospital, are also clearly occupied by specialists themselves who have and require expensive equipment and facilities (surgical rooms, HVAC systems, large passageways for accessibility compliance). However, in my experience, the hospital construction analogy doesn't resonate with the experience or imagination of most business stakeholders. Why exactly, might be a subject for another post.
A critique of the gardening metaphor:
A garden metaphor is less useful if you are building something that you want to operate at scale, with, say, millions of users. Etymologically, a garden refers to an "enclosure" and my experience suggests that that most people conceive of a garden as small and most often managed by a small number of relatively low-wage workers.
Three Alternative Metaphors
Considering the points above, it's natural to consider alternatives that emphasize the complexity, specialization, and scale requirements necessary to build a modern software application that adds business value. Here are my three favorites:
Analogy |
Good for Emphasizing |
Highway construction |
Painstaking coordination between stakeholders (neighborhood meetings, politics, federal funding, approvals from affected municipalities, top-down long-term planning by civil engineers, public comment periods). The long-range effects of important design decisions (consider New York vs. Los Angeles). |
Founding a modern nation state |
Security (customs), Diplomatic issues (negotiations with legal departments), Bureaucracy (legal and administrative systems), Currency systems (central banks, information, and monetary policy). |
Space mission |
Risk (e.g. Challenger Explosion), Exciting opportunities in new frontiers, cutting edge science-backed research, rigorous testing, professionalism. |
I started using the highway construction analogy after listening to a fascinating podcast about the "Big Dig" - which was, at the time, the most expensive highway project in U.S. history. This one is good for a very not romantic but extremely necessary of software development - gathering stakeholder buy in. Obviously, this is most useful in contexts where everyone knows that the project is useful but where political will needs to be mobilized (probably because it's not very sexy).
I started using the founding a modern nation state when I was in a situation where I needed to emphasize an effort to different modules of the same website into a "federation" in which these separate entities submitted to a new set of administrative standards (In the analogy, the different modules were like different colonies that had their own cultures but now needed to come together just like the original American colonies needed to in order to form the United States). This is useful because it can inspire a revolutionary feeling to team members who need a way to understand why administration is important. If you want to emphasize the less sexy parts of software development, you can talk about the extensive bureaucratic functions of a modern nation state (post office, central bank, customs, trade negotiations, judicial systems for governance). The benefit of this analogy is that most people don't understand that the modern full-stack developer has to worry about all of these things. Often, I find, subject matter experts don't know, for example, how much time a developer needs to devote to making sure that that feature doesn't expose a security risk (customs), or establishing standards for how different pieces of an application communicate with one another (e.g. postal service if you want to emphasize the system, central bank if you want to emphasize the value of the information being transmitted).
I started using the space mission analogy when there was some discord in one of my project teams and wanted to both respect the professionalism of members of the team and politely reframe the issue as being larger than ourselves. The Challenger Disaster analogy that this affords is useful if you need to remind people of stakes of failure. Finally, this analogy inspires the imagination in a way that others don't - there is something inherently interesting about "the final frontier" of space where - unlike the garden - there are clearly new horizons to explore and develop.
I started using the founding a modern nation state when I was in a situation where I needed to emphasize an effort to different modules of the same website into a "federation" in which these separate entities submitted to a new set of administrative standards (In the analogy, the different modules were like different colonies that had their own cultures but now needed to come together just like the original American colonies needed to in order to form the United States). This is useful because it can inspire a revolutionary feeling to team members who need a way to understand why administration is important. If you want to emphasize the less sexy parts of software development, you can talk about the extensive bureaucratic functions of a modern nation state (post office, central bank, customs, trade negotiations, judicial systems for governance). The benefit of this analogy is that most people don't understand that the modern full-stack developer has to worry about all of these things. Often, I find, subject matter experts don't know, for example, how much time a developer needs to devote to making sure that that feature doesn't expose a security risk (customs), or establishing standards for how different pieces of an application communicate with one another (e.g. postal service if you want to emphasize the system, central bank if you want to emphasize the value of the information being transmitted).
I started using the space mission analogy when there was some discord in one of my project teams and wanted to both respect the professionalism of members of the team and politely reframe the issue as being larger than ourselves. The Challenger Disaster analogy that this affords is useful if you need to remind people of stakes of failure. Finally, this analogy inspires the imagination in a way that others don't - there is something inherently interesting about "the final frontier" of space where - unlike the garden - there are clearly new horizons to explore and develop.
RSS Feed
