Different Work: Why the Manufacturing Mindset Does Not Apply to Software Development

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. Roy Miller explains why.

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.