Wednesday, February 10, 2010

Occam's Razor Bites Again

For those who contend that there are lessons in failure, this week, I'm inclined to agree wholeheartedly. One lesson I have recently had cause to ponder is that of the number of people required to complete a task. I have been watching Blood, Sweat, and T-Shirts on the Green station here in Boston, which appeared with no warning on my cable lineup. On that, they examine the human cost of our cheap clothing by taking spoiled British hipsters to work in Indian sweatshops. It's like an authentic version of Paris Hilton's Simple Life.

One such sweatshop is a well oiled machine of garment sewing, pressing, and buttoning. Hundreds of people churn out thousands of garments a day, each doing their little bit of the work. One only does collars. Another only does buttons. And so on. The second, more repugnant, filthy hovel of a sweatshop has each worker producing a whole garment, top to bottom. For the moment, let's assume that garment-making is highly skilled labor (those British Hipsters couldn't do it, actually).

If this is the case, then factory #1 would have a heck of a time cutting their burn rate if orders drop. They have 20 skilled people doing 20 stages of sewing and pressing, and none could easily pinch hit for the other, since lapels are fundamentally distinct from hems. When orders drop, how can they scale back?

Factory #2, on the other hand, can easily cut employees down to even a single one, since each employee is an island, completely self-sufficient. It's clear that Factory #1 is modeled in the Ford-ian style of manufacturing that is the hallmark of the industrial revolution. However, it has some distinct disadvantages when demands shift.

I can't help but map that back to my own industry - software development. If you are building software that requires such specialized skills that it fundamentally operates as Factory #1, cutting burn is very challenging. If, on the other hand, you're building an amazing fleet of iPhone apps, each of which require 1-2 specialties (say, graphics and code), then you can scale up or down pretty fluidly (human resources issues aside) to meet demand.

It never occurred to me that the very architecture of a software product impacts its feasibility as an investment and as a company.

No comments: