Frederick Taylor was the first industrial engineer. Others before him had studied efficiency in factories, but Taylor came to the field with an intensity and charisma that created the whole field of industrial engineering. Through his work and that of his disciples, most notably Frank and Lillian Gilbreth and Henry Gantt, he brought a rigorous and compelling presentation of the case for systematically improving factory productivity. He picked a powerful metaphor for his teaching, Scientific Management.

When picking descriptive names, it helps to pick a name whose opposite is unappealing. Who could possibly be for “unscientific” management? What Taylor meant by “science” was that to improve factory productivity, he would apply the methods of science: observation, hypothesis, and experimentation. He would observe a worker at a task, devise alternative ways of performing the task, observe these, and pick the best way to do the task. (One of his mottoes was “The One Best Way”.) All that was left was to standardize the execution of that task through the whole factory to guarantee improvement.

I don't have space here to describe all the technical, social, and economic impacts of Taylorism, as it came to be called. The bibliography gives you several opportunities for further reading. While Taylorism has some positive effects, it also has some serious shortcomings. These limitations come from three simplifying assumptions:

Why is Taylorism important for software engineering? No one walks around a development shop with a clipboard and a stopwatch. The problem for software development is that Taylorism implies a social structure of work. While we've lost the rituals and trappings of time-and-motion studies, we have unconsciously inherited this social structure and it is bizarrely unsuited to software development.

The first step of social engineering in Taylorism is the separation of planning from execution. It is the educated engineers who decide how work is to be done and how long it will take. The workers must faithfully execute the assigned task in the assigned way in the allotted time and all will be well. Workers are cogs in a machine. No one wants to think of himself as a cog.

Echoes of Taylor can be heard in software development any time a person in authority makes or changes an estimate for someone else's work. The echoes can also be heard when an “elite” architecture or framework group prescribes precisely how work should be done by someone else.

The second step of Taylorist social engineering is the creation of a separate quality department. Taylor assumed that workers would “soldier” whenever possible (work slowly or badly but not so slowly or badly as to be noticed). He created a separate quality control department to ensure that workers not only worked at the right pace but in the specified way, in order to achieve the right level of quality.

Many software development organizations are directly (and even proudly) Taylorist in having a separate quality organization. Having a separate quality department sends the message that quality is exactly as important to engineering as marketing or sales. No one in engineering is responsible for quality. Someone else is. Putting QA as a separate department within the engineering organization also sends the message that engineering and quality are separate, parallel activities. Separating quality from engineering organizationally makes the job of the quality department punitive instead of constructive.

I am not saying that quality, architecture, or frameworks are unimportant to software development. Quite the contrary. They are too important to be left to Taylorist social structures that impede the flow of communication and feedback vital to creating working, flexible, and inexpensive software in a changing world. We'll see in the next chapter some more recent ideas from the world of manufacturing that provide alternative social structures to meet these goals of productivity and quality.