Vivek Haldar
This belief stems from a misunderstanding of how software is created, and what Taylorism truly means in that context. It is tempting to make parallels between industrial production and writing software, and indeed, Carr is not the first to make the leap. At the dawn of the field, the lament was that “the software industry is not industrialized.” They holy grail was “reusable components” – lego-like blocks that could be snapped together to make a specific end-product. Forty years later, we’re nowhere near that goal.
Industrial manufacturing is all about reducing uncertainty and variance in both the process (“build 10 nuts a minute”) and the product (“the nut’s diameter must be 10mm with a standard deviation of 0.1mm”). Taylor’s time and motion studies observed the process, rooted out inefficiencies and drove down variances. A worker turning a lever at a given frequency, not pausing for reflection or applying judgment, is better for predictably cranking out widgets.
But when it comes to creating software, pausing for reflection and applying judgment cannot be eliminated. Indeed, they are central to the entire endeavor. The inception, design, implementation, maintenance, and debugging of software is anything but a predictable assembly line. There are questions, uncertainties and leaps of faith at every step, in spite of insights gleaned from vast amounts of data.
Yes, Google, and every software company to some degree, is data-driven. Data shines some light on an activity that is otherwise filled with chaos and uncertainty. Software engineering deals with complex artifacts, and data helps. It helps answer questions about usage unambiguously, as Carr rightly points out. Which features are users actually using? What layout gets more clicks? However, these are still answers only about the finished product. The process by which that product actually gets made is still not a predictable, reductionist assembly line. It is a different a world than the one Taylor imagined, and then created, for manufacturing.
But the most important disconnect between Carr’s fantasy of a Taylorist software factory and reality is in the role of programmers in creating software. In Taylor’s worldview, workers are unskilled, replaceable cogs. Programmers are anything but. (There might be some author bias here, but still). There is a wide variance in the productivity of programmers, and the best ones are more than an order of magnitude better than the average ones. In this sense, programmers are more like writers, or even artists. This difference is at odds with Taylorism’s thesis of workers having roughly similar productivity, and hence being replaceable.
Most modern science is intensely data-centric. New insights are often gleaned by extracting patterns from vast amounts of data. Does this mean the entire enterprise of modern science is Taylorist, with scientists nothing but faceless cogs, freely replaceable? Of course not.
Carr is making the mistake of noticing one central tenet of Taylorism – measurement and data – in an enterprise and labeling the entire entire enterprise Taylorist. There is another name for this method of creative, intelligent agents using data and measurement in the pursuit of complex tasks – empericism.
[Full disclosure: I’m employed by Google. These are my own views, not Google’s.]
Taylorism in the modern tech industry
I’m reading Nicholas Carr’s “The Shallows”, and thoroughly enjoying it. Whether I agree with everything he says or not, he is eloquent and thought-provoking.
One of the chapters in the book is “The Church of Google”, in which Carr examines the way Google operates, and draws the conclusion that it is Taylorist:Google’s Silicon Valley headquarters… is the Internet’s high church, and the religion practiced inside its walls is Taylorism. The company, says CEO Eric Schmidt, is “founded around the science of measurement.” It is striving to “systematize everything” it does. “We try to be very data-driven, and quantify everything,” adds another Google executive… What Taylor did for the work of the hand, Google is doing for the work of the mind.(Emphasis mine.)
This belief stems from a misunderstanding of how software is created, and what Taylorism truly means in that context. It is tempting to make parallels between industrial production and writing software, and indeed, Carr is not the first to make the leap. At the dawn of the field, the lament was that “the software industry is not industrialized.” They holy grail was “reusable components” – lego-like blocks that could be snapped together to make a specific end-product. Forty years later, we’re nowhere near that goal.
Industrial manufacturing is all about reducing uncertainty and variance in both the process (“build 10 nuts a minute”) and the product (“the nut’s diameter must be 10mm with a standard deviation of 0.1mm”). Taylor’s time and motion studies observed the process, rooted out inefficiencies and drove down variances. A worker turning a lever at a given frequency, not pausing for reflection or applying judgment, is better for predictably cranking out widgets.
But when it comes to creating software, pausing for reflection and applying judgment cannot be eliminated. Indeed, they are central to the entire endeavor. The inception, design, implementation, maintenance, and debugging of software is anything but a predictable assembly line. There are questions, uncertainties and leaps of faith at every step, in spite of insights gleaned from vast amounts of data.
Yes, Google, and every software company to some degree, is data-driven. Data shines some light on an activity that is otherwise filled with chaos and uncertainty. Software engineering deals with complex artifacts, and data helps. It helps answer questions about usage unambiguously, as Carr rightly points out. Which features are users actually using? What layout gets more clicks? However, these are still answers only about the finished product. The process by which that product actually gets made is still not a predictable, reductionist assembly line. It is a different a world than the one Taylor imagined, and then created, for manufacturing.
But the most important disconnect between Carr’s fantasy of a Taylorist software factory and reality is in the role of programmers in creating software. In Taylor’s worldview, workers are unskilled, replaceable cogs. Programmers are anything but. (There might be some author bias here, but still). There is a wide variance in the productivity of programmers, and the best ones are more than an order of magnitude better than the average ones. In this sense, programmers are more like writers, or even artists. This difference is at odds with Taylorism’s thesis of workers having roughly similar productivity, and hence being replaceable.
Most modern science is intensely data-centric. New insights are often gleaned by extracting patterns from vast amounts of data. Does this mean the entire enterprise of modern science is Taylorist, with scientists nothing but faceless cogs, freely replaceable? Of course not.
Carr is making the mistake of noticing one central tenet of Taylorism – measurement and data – in an enterprise and labeling the entire entire enterprise Taylorist. There is another name for this method of creative, intelligent agents using data and measurement in the pursuit of complex tasks – empericism.
[Full disclosure: I’m employed by Google. These are my own views, not Google’s.]