I’ve heard it said that there are basically two ways to understand a thing: (a) by direct experience, or (b) through metaphor. People who need or want to understand software development, but who don’t develop software themselves, often rely on metaphor. They are like the six blind men who try to describe an elephant. (That was a simile, not a metaphor.)
Software development is a unique sort of activity, with its own distinctive characteristics. Yet, as a way to try and understand the nature of software development, people have used various metaphors to describe it. Software development is a wall, or a rope, or a spear, depending on which part of the elephant a non-developer happens to touch.
Metaphors are something like conceptual models. Little ones. As George Box wrote, all models are wrong, but some models are useful. The popular metaphors about software development are wrong. They are wrong because they do not capture the exact nature of software development completely. The metaphors are also useful. They are useful because each one of them does capture some interesting aspect of software development in terms that people can relate to.
Software development is construction
When you build a physical structure, the first thing to do is prepare the ground. For a housing development this means shaping the contours of the land for drainage, installing the infrastructure for water, sewage, and electricity, and building roads to access the lots. Next, you lay the foundations of the houses and bring the infrastructure connections into the space of the house. When a foundation is ready, you do the framing. Then you add floors, walls, insulation, wiring, plumbing, and so forth. You add a roof and add the outer façade. You install plumbing and electrical fixtures and finish the interior surfaces.
When you develop software, you start with the technical infrastructure necessary to support applications – servers, operating systems, database management systems, networks, etc. Then you create the architecture of the application – its overarching logical structure. Then you build up the application code layer by layer, starting with the “lowest” or “back-end” layer and building toward the “front end” or “user interface” layer.
Software development is engineering
When you engineer a machine or electronic device, you begin by carefully specifying all the components and their interfaces in detail. You design the device according to well-known, professional engineering principles and practices. Then you make the components. Then you assemble the components according to the defined interfaces. After the pieces are assembled, you test the device to make sure it works as expected.
When you develop software, you begin by carefully specifying all the components and their interfaces in detail. Then you write the individual components according to well-known, professional software engineering principles and practices. Then you integrate the components according to the defined interfaces. After the system is integrated, you test it to make sure it works as expected.
Software development is manufacturing
In a manufacturing process, widgets are produced on a production line according to a standard, predefined design. A goal of manufacturing operations is to ensure that there is no variation from one widget to the next. Quality control is therefore concerned with minimizing variation. Once you know how to produce a widget, the manufacturing process is just a matter of repeating the same steps again and again.
When you develop software, you follow a defined series of steps whose inputs and outputs have been clearly laid out in advance. It is a repeatable activity in that every application is created by repeating the same sequence of steps again and again.
Software development is product development
When you develop a new product, you begin with a concept and you refine the concept incrementally through a series of prototypes, soliciting feedback frequently as you go along. Eventually you arrive at a concept for the product that meets customer needs and represents a sound design. Because a new product is new, and not merely a copy of something that already exists, it is not reasonable to try and predict every detail about its final form before you begin working on it. You have to discover the final form of the product through a series of feedback loops.
When you develop software, you are in effect developing a new product. After all, if a program already existed that did the same thing as you are trying to do, then your customers could simply use that program instead of asking for a new one. Therefore, it is reasonable to approach the task by iterating through a series of prototypes, soliciting feedback from knowledgeable people and potential users as you go along. That way you eventually arrive at a final design that meets everyone’s needs.
Software development is art
When you create art, you are inspired by an idea and you apply your natural creativity (as well as learned technical skills) to realize your vision. You can’t easily describe the creative process, as it tends to forge its own path as you go along. As the work emerges, it causes the vision to change. As the vision changes, the work emerges differently; and so on.
When you develop software, you are inspired by an idea and you apply your natural creativity (as well as learned technical skills) to realize your vision. You can’t easily describe the development process, as you tend to jump between different activities – analysis, design, test, code – frequently and unpredictably, depending on how the work progresses. As the code emerges, it causes the vision to change. As the vision changes, the code emerges differently; and so on.
Software development is craftsmanship
A craftsman is an artisan who produces functional objects with a high level of attention to detail, usability, and beauty. A craftsman improves his skills and his appreciation for the work gradually, day by day over a lifetime, learning by working alongside master craftsmen, by teaching apprentices, and by refining his/her work through direct experience.
When you develop software, you pay close attention to details of software design and code structure. Well-structured code has a kind of intrinsic beauty, of the sort that occurs when form and function blend seamlessly. The software craftsman develops an eye for this sort of beauty through many years of mindful practice, learning by pair programming with fellow software craftsmen and by refining his/her work through direct experience.
Software development is a social activity
Human beings are social creatures by nature. This attribute harks back to the necessities of survival our ancient ancestors had to manage. A lone human is no match for a top predator such as a cave bear or sabre toothed cat. Nor can a lone human bring down a mammoth and process its enormous carcass without help. But acting in a collaborative group to achieve a common goal, humans are all but unstoppable. They do their best work in groups, feeding off one another’s ideas and building atop one another’s successes to achieve outcomes no single one of them could have imagined beforehand, and that no single one of them could ever hope to achieve alone.
When we develop software, we do it as a group activity. There is a team comprising individuals who possess a variety of specific skills, as well as some who are adept at perceiving the big picture and keeping priorities in mind. They work in concert with a group of people who will consume and use the product, or who understand the needs of others who will do so. Together, this group can produce software of greater utility and higher quality than any one of them could have done by working alone.
Software development is an organizational learning mechanism
In a double-loop learning organization, all activities and operations provide new information about what is effective and what is not effective. New information is folded back into the organization’s operations, changing its goals as well as its procedures.
When we develop software, the process by which the product evolves during its initial development and over the course of its lifetime in production or in the market generates new information about how the product can be improved, and about how the process of creating new products can be improved. In this sense, the activity of developing software is, itself, an organizational learning mechanism that is more powerful in many ways than formal training classes or other conventional forms of learning.
When is it a wall and when is it a spear?
Well, it’s never really a wall or a spear, and it’s always both. Each of the six blind men is wrong, and all of them are right. In the course of developing a new business application, the activities can sometimes resemble one or more of the metaphors.
When we are determining the business capabilities that we want to support, the work is an organizational learning mechanism and a social activity. When we have determined the non-functional requirements, we may discover that we must upgrade the technical environment to accommodate new functionality, new workloads, or new quality of service levels. At that point, we’re doing construction work — shaping the contours of the ground and laying down basic infrastructure.
When we are determining what the user work flow and user experience ought to be, the work is akin to art. If we have chosen to use a framework and prebuilt components to help us develop the new application, then assembling those prebuilt components is not unlike a manufacturing operation.
When we are writing the business logic for the new application, the work is a combination of engineering and craftsmanship. When we solicit feedback from stakeholders based on solution increments, it is an organizational learning mechanism. When we collaborate across job functions and within our development team, the work is a social activity. The work becomes art combined with engineering when we encounter unusual problems that don’t have an out-of-the-box solution.
All the metaphors are meaningful in some context, at some level, to some degree. Yet, when we combine them all we still don’t have an elephant. Software development just is what it is, and it isn’t anything else. If you try to grasp the nature of software development solely through metaphor, you will be grasping smoke.
In Stranger in a Strange Land, Robert Heinlein introduced the Martian word, grok. The word was quickly adopted as a “standard” English word. It means “to understand deeply.” In Martian, it also means “to drink.” In the novel, the only way the Martians could truly understand something was to consume it. Once they grokked a thing, it no longer existed. The Martians integated the thing into themselves, and in the process integrated themselves into the thing.
Fortunately, we Earth people needn’t destroy software development in order to understand its nature. Humans have a word, in the language they call Spanish, that means both “to know” and “to taste:” saber. To understand the nature of software development, you have to taste it. That is, you have to do it.
Metaphor will only take you part of the way toward understanding. Sometimes, for some purposes, part of the way is far enough.
But not always.
Dave,
Very nice post. I can see all the models bear some resemblance to software development. However, I would like to get your take on the level of usefulness for each.
IMO, I think 2 in particular have more distorting characteristics than they offer on the useful model side: construction and manufacturing.
From my experience, the most dysfunctional project management and governance mechanisms exist because software development is incorrectly and primarily seen as a blend of construction and manufacturing activities.
It seems you can slice it another way too. The more deterministic activities are construction and manufacturing. The more non-deterministic activities are engineering, product development, art, craftsmanship, social, and learning. From my observations, people and organizations struggle the most when software development is treated as a deterministic activity.
Thoughts?
Interesting observation, as the construction and manufacturing metaphors seems to be the most widely used. I agree with your assessment of what happens when development is seen as a blend construction and manufacturing. I also agree that treating software development as primarily a deterministic activity leads to problems.
More to the point, problems ensue when people read too much into the metaphors. There’s nothing wrong with a metaphor or analogy to help people understand something. There is something wrong – very wrong – when we start to mistake the metaphor for the real deal.
In any software development effort beyond the simplest and smallest, there will be a variety of activities. Some of them will be more deterministic, as you put it, than others. The proportion of deterministic and non-deterministic activities depends as well on the nature of the work. Some development is fairly predictable and some calls for a collaborative exploration of the solution space involving both producers and consumers of the product.
As with so many other aspects of IT work, the answer is: It depends.