Different Work: Why the Manufacturing Mindset Does Not Apply to Software Development
This chapter is from the book
This chapter is from the book
This chapter is from the book
Taylorism, and the manufacturing mindset based on it, makes sense for efficiency optimization problems like manufacturing. It makes very little sense for other kinds of problems. As it turns out, software development isn't like manufacturing at all. It's a different kind of work to solve a different kind of problem, despite what their learning and training tells most managers. The manufacturing mindset simply doesn't apply to software development. Software development doesn't fit.
Bad Logic
Taylor wrote The Principles of Scientific Management in 1911. By the 1920s, his theories and practices had revolutionized industry. By the 1950s, about the time software development made its debut, no one really argued much about Taylor's theories. People simply accepted them as fact, and as the standard for management. They added some bits to create a more humanizing workplace, but Taylor's underlying principles remained. In his biography of Taylor, The One Best Way, Robert Kanigel describes Taylor's influence this way:
“[S]cientific management,” as well as its near synonym “Taylorism,” have been absorbed into the living tissue of American life….Taylor's thinking, then, so permeates the soil of modern life we no longer realize it's there.1
Whether anybody ever made a conscious decision to apply scientific management to software development is tough to know, although it could have happened. In any case, efficiency optimization was ingrained in the American psyche by the time software development came along. People took it for granted that the same thinking and management practices applied, and would produce the same results. They began managing software development like machine tooling, and software developers like steel workers.
If anybody had forced managers to say why they assumed the manufacturing model would work, I imagine their logic would have been:
-
We produce stuff.
-
We produce software.
-
Efficiency optimization works well for other stuff we produce.
-
Therefore, it should work for software development.
In a scene from Monty Python's The Holy Grail, King Arthur happens upon a gathering of townsfolk who want to burn a witch. Sir Bedevere, apparently the law in that town, wants to be sure the citizens are positive she's a witch. He gives them some logic to follow:
-
You burn witches.
-
You also burn wood.
-
Witches burn because they're made of wood.
-
Wood floats.
-
Ducks float.
-
If the accused lady weighs the same as a duck, she must be made of wood, and is therefore a witch.
Software managers over the years weren't that silly, but their logic was just as bad. The manufacturing mindset dominates because, bad logic or no, it's natural for managers to think that way. They don't question it because it's just the way things are…and always have been. It was natural to begin with, and constraints on managers reinforced it. Engineers told them the cost of change was high, and software development managers certainly saw that often enough. Given a predisposition to the manufacturing mindset, the idea that predicting things better and controlling them more effectively would reduce cost made good sense. Thus, management attempts to make McSoftware.
The manufacturing mindset is consistent with the way most software development managers learn to manage projects. It's natural. It has become a habit, and people tend not to question habits. But it doesn't make much sense for solving the real problem, because it's based on some assumptions that don't apply.