The “Software Factory” Metaphor

Posted by Robert Merrill on November 22, 2008 under Uncategorized | Be the First to Comment

The “Software Factory” metaphor has been around for a long time–at least 20 years. Now I see it’s become associated with an award-winning book and a Microsoft methodology. It’s no wonder that the Software Factory metaphor is attractive to buyers of software. It calls to mind predictability and low cost.

But what if it’s wrong?

Metaphors create clarity–that longed-for A-HA! Bad metaphors create the illusion of clarity, and cause people, especially managers and executives, to charge ahead, heedless of warning signs, until there’s undeniable trouble. The author of the metaphor may understand the limitations and subtleties, but those get lost, especially when the metaphor is really attractive.

Now, predictability-and-low-cost is the Holy Grail of software development, and ever since Fred Brooks, people have been on a quest for the Holy Grail with a gun full of Silver Bullets. People have always longed for the Software Factory, and maybe it’s finally arrived in the book by Greenfield, Short, Kent, and Crupi. (I admit, I haven’t read the book yet.)

Or maybe the predictability and low cost associated with software are really here, already, and we’re just not appreciating them. It’s only natural that we think of the fruit of our own labors, especially if it’s tangible, as The Product. We make software, so software must be the product. But is it?

Drill Bit–or Hole Factory?

Consider drill bits. The last time I bought a drill bit, I didn’t really need a drill bit. What I needed was a hole of a certain size that my hole factory–my trusty Black and Decker–could not produce. So I retooled my factory–literally–and then I could make 9/16 inch holes with abandon, at low unit cost and with a lot more precision than with a mallet and a chisel.

The Software-As-Factory produces a user experience. This metaphor leads to an outward, experience-and-value focus.

Now consider software. People buy this product, but they don’t put it on the wall to admire it. They don’t eat or otherwise consume it. They use it to accomplish or experience something. They use it over and over, as they use tools of other kinds, or as a company uses a factory. Garbage goes in, and altered garbage comes out, but quickly and (usually) predictably. Sometimes it lets them do things they already could, only faster and with fewer errors. And it lets people do things that weren’t even possible before, or that were prohibitively expensive and time-consuming without computers. We’re surrounded by low-cost, predictable information access and experiences. Low-cost, predictable things come from factories–in this case, from computers controlled by software.

What if the Software IS the Factory?

A Tale of Two Metaphors

Consider where these two metaphors lead us.

The Software Factory produces software. This metaphor leads to an inward, process-and-cost focus.

The Software-As-Factory produces a user experience. This metaphor leads to an outward, experience-and-value focus.

Now, it isn’t that the Software Factory can’t produce high-value software that creates great user experiences. It’s just that it tends to lump those concerns in with factory-floor concerns about getting the product–the software–out the door, at minimum cost. Usability and value become second-order attributes of the product.

The Software-As-Factory metaphor separates concerns more cleanly. We want to produce a valuable and delightful user experience–the end product–reliably and at low cost, and for that, we need a factory. Maybe we can retool an existing factory, or maybe we will need to build a new one. Will there be just one factory–a hosted application–or will there be many locally-operated factories–a shrink-wrap application? Does the factory produce a single product, or a variety? If a variety, the factory itself might be complex to operate and require special skill and training.

Notice that the Software-As-Factory metaphor encourages us to see past the increasingly artificial business-technology divide. There are people who use the products of factories–the user experiences–as is. Some of them learn to retool the factory to produce a short run of a customized experience for the use of a smaller number of end customers. Think of the office Excel whiz. Finally, there are the people who design and build factories–professional, full-time software developers. Maybe they are the Industrial Engineers of the information-technology world.

Product Manufacturing versus Product Development

Under the Software-As-Factory metaphor, software development is more like product development than product manufacturing. This is not my idea. Mary Poppendieck quotes Kosaku Yamada, Chief Engineer of Toyota’s Lexus line, “The real difference between Toyota and other vehicle manufacturers is not the Toyota Production System, it is the Toyota Product Development System.” In other words, the Toyota advantage isn’t that they run great factories (though they do). It’s that they conceive of great products, and implement the factories to make them, better than anyone else. Mary Poppendieck also cites 3M (where she spent a good portion of her career) as another example of product development excellence.

Now I’m fired up to go learn more about the Toyota Product Development System and how that relates to the Software-As-Factory metaphor. I also need to read Software Factories because it is well reviewed and I’m sure I will learn a lot from it.

But the idea of a software productivity breakthrough, as opposed to a welcome yet still incremental improvement, through software development tools? Not if the software is the factory and not the product. Call me skeptical.