Software Development is Design Work, not Construction Work
Posted by Charlie Rudd on Thu, Dec 01, 2011
In my last post, we discussed why software development is more like designing than building. The following diagram illustrates the point:
Construction is building to specification. In the case of a house, the construction is done by tradesmen and the specification is a blueprint. In the case of a software system, the construction is done by a compiler and the specification is the source code. In both cases, the work to produce the specification is design work. So just how different is building to specification from design work and how might this change our expectations regarding software development?
The first thing to keep in mind is that a comprehensive specification not only provides an objective way to verify delivery of the desired outcome, but also entails an objective definition of all the work that needs to be performed. Each source code statement determines precisely what “work” the compiler will perform. The blueprint makes clear everything that the tradespeople need to do. If you wanted to, you could count the number of nails you will need and how many times you will need to hit the hammer. Or to put it differently, you could develop a comprehensive task-level WBS from the specification. This kind of work is reducible to a finite set of repeatable tasks and procedures that can be abstracted as labor. Such work is inherently automatable. In principle, a machine could be built or programmed to perform this work and when people perform this work, they are in effect part of a larger virtual machine. Switching people operating within a virtual machine such as an assembly line is comparable to swapping out parts of any other machine: the machine’s output does not change. In fact, that is the whole point. This spec-driven approach to defining and managing work is the approach known as scientific management (or Taylorism) that was developed to optimize manufacturing production. Let’s call this kind of work fungible work, and the production process where it is performed the fungible work machine.
The fungible work machine is a one-trick pony. The inputs and the outputs are always the same. When people are valued for the part they play within a fungible work machine, they are valued as standardized labor units and not as unique human beings.
Now let’s contrast construction or fungible work with design work. Design work taps human creativity. The outcome emerges over time and is not predictable. To a large degree, the outcome is not tangible. The outcome is some kind of specification to produce something tangible. Design work is a form of knowledge work. Knowledge work involves analyzing, sharing, elaborating, and validating ideas. Developing ideas usually requires different perspectives, which requires discussion and collaboration with others. It’s tough to get to the bottom of human creativity. Attempts to reduce this kind of work to elemental procedures fail. When people put their heads together and create something new it’s often seems like a miracle.
When it comes to knowledge work, who does the work makes all the difference. You change the person and you change the outcome. The outcome is unpredictable. To succeed, knowledge work often depends upon collaboration and experimentation. In contrast to fungible work, people add value through their unique human characteristics of creativity, thinking, and communication; not by contributing generic labor.
Fungible work and knowledge work could hardly be more different from each other. They operate under different conditions and in different environments. Perhaps the most important contribution of Agile software development is the recognition that software development is fundamentally knowledge work not fungible work, as past development methods and practices have assumed.