Wednesday, November 3, 2010

Manufacturing Software

Matt Heusser wrote a great riff on "Quality" as interpreted by American business. Go read it and come back.

Back? Great.

So here's the problem with many of the examples in Matt's piece: they're all about manufacturing. Taylor wasn't concerned with the software engineer; he was concerned with paper and steel manufacturing. Lean principles came from car factories. All these things are concerned with building something consistently and doing that as efficiently as possible. Innovation isn't intended to make something different or to make the product better; it's intended to make the product more consistent and to use less effort to make that product more consistent.

So now we apply this to software!

After all, software is about building the same thing over and over and simply doing it more efficiently and.... wait. That doesn't sound right at all.

This is the fundamental breakdown: as software professionals we seek innovation in the product itself, not innovation in the process used to create the product.

There is a process of manufacturing software. There is a compiler that manufactures bytecode. There is a library that calculates a hash. Those are manufacturing processes in the sense that the way we improve quality is to produce the same end result (the same bytecode, the same hash) more efficiently and more consistently. Taylor's "labor" - the workers actually doing the manufacturing - is all software for us now. We, the developers and the testers, we are Taylor's management.

We as management have responsibilities, too. It is our responsibility to seek better products for our workers (compilers) to build. It is our responsibility to seek out inefficiencies in the manufacturing process (are we using SHA-2 hashes when MD5 will do?) and to correct them. We are the ones who must conduct time and motion studies (only we generally call this optimizing the software or performance analysis).

So yes, go ahead and use a manufacturing analogy - just recognize that the humans are all on the "management" side of that analogy. (Yes, even those of us that don't have "manager" in our title.) Taylor wanted to make laborers into highly efficient drones with focused areas of expertise. In software, he has succeeded - a computer program makes a highly efficient drone with a focused area of expertise. It's time to move on; it's time to think about what we're building instead of how we're building it.


  1. Hey thanks, and I really do get that software development is more like engineering than the physical assembly of the car. I /*was*/ trying to point out that even in manufacturing, tho, the companies that win are engaging the whole person with the work, empowering self-directed work teams to solve problems.

    I do agree that knowledge workers look more like (traditional, 19th century) management than they do (traditional, 19th century) line workers.

    Actually, if memory serves, Peter Drucker (another guru) wrote about 1950 that tomorrow's knowledge worker would have more autonomy, education, and scope of responsibility than the foreman of today.

    Guess what.

    I work up.

    It's 2010.

    And, according to Drucker, it has become tomorrow.


    Seriously, fair point, good post. :-)

  2. Matt,

    Thanks for the response - it sounds like we're in violent agreement! :)

    And yes, Drucker was one of the first to point out that "scientific management" is really what he called "knowledge management" (sound familiar?), and that it applied outside the manufacturing realm to more general management. I dropped the reference because I didn't have a source I liked to cite.

    And yes, I believe we may have officially arrived at Drucker's tomorrow. I'm still waiting for hoverboards and personal jetpacks, but perhaps that's someone else's tomorrow!

  3. I made a point once that as creators of software, we do not manipulate physical objects. We manipulate abstractions: concepts, processes, algorithms, ideas. That is fundamentally different work than manufacturing or engineering. The rest of my points I made here: