Yes, Ford paid a "little bit better", just twice as much as other workers in the same industry:

http://history1900s.about.com/od/1920s/p/henryford.htm

Eric --Great article.
I was involved in many of the same projects you mention. One where maybe our paths crossed was all the talk about the Software Factory (OMG, I think, but the I'm impaired by the fog of decades).
It is not that the Ford analogy is bad; it's just that no one ever built the software assembly line.
-- Dennis

Yes, that's a good point. Building a mass produced item such as an auto or a PC involves doing the same thing over and over again, while building a software application involves doing something once.

I suppose the analogy is intended to relate to the level of the fastener - to the threading of screws and nuts - more than the size or shape of the parts being assembled. In software terms this would mean the ability of any program to export a standard interface by which any other program could call it.

I believe the question you raise is whether this would really help anything, since putting together a series of programs to create an application (whether some percentage of them are reused or not) is really a one-off activity in which customization is not only to be expected but does not hurt anything either.

But if we have it backwards, and the Ford analogy is backwards, what replaces the idea of a standard interface to help improve productivity and lower the cost of creating applications?

This article really got me thinking, and I have to say that I agree that Ford's innovations with mass-production and factory assembly lines in general are a really bad, broken analogy for the software industry to try and achieve. The point with building the Model-T, is they were building the same thing, over and over again. That takes no skill. Computer hardware benefitted from that analogy -Modern PC's got cheap and easy to mass produce when motherboards with expansion slots were invented, and you could slap together different machines by plugging in different cards. What makes that work is that the BUS is static - you write your firmware to work with the standards, nothing changes in the way the firmware on your sound card talks to the motherboard. When the standards change (PCI? VL-BUS?) then the card manufacturers need to adapt to the new interface and create a new component.

I’d say that what we’re trying to do with SOA, is design a new car with every application. The fact that they’re all made of more or less the same parts is almost irrelevant because (unless we’re talking the slant-6 from the 60s and 70s) those parts have to be adapted to each new use. A PC's operating system and the motherboard's BUS are the "orchestration" piece, and those are not adaptable by the people slapping together PC's - what we're doing with SOA and "applications" is essentially creating a new OS and BUS every time we try to compose a different application from our services.

And the thing is, applications are by the very nature of software, "one-offs".

Hmm.

Excellent food for thought.

Thanks.

Yes that's true today. But can't the software industry change? Can't it learn from other industries and adopt scientific and industrial methods for development? Why does it need to stay a craft industry? Labor is the biggest single expense in IT. Other industries, including the automobile industry, have made the transition.

It is nice to see more people looking towards Toyota and Lean Thinking to advance the field of software. I am afraid that in this case though, the wrong lessons are being learned. You see, the bottlenecks in software aren't in production. We don't build software, and we certainly don't produce it. We develop it. So the best lessons to be learned are currently in lean product development IMHO.

Tom,

That's a good point. Hal Hildebrand made a similar point in his blog reponse:

http://www.tensegrity.hellblazer.com/

Design is probably a more critical aspect of the process than either interchangeable parts or the division of labor. Perhaps what we really need are better design tools, including a way to design a good project that splits up the work and supports checking the results.

The Ford analogy isn't bad except you leave out the part the designers/engineers played in developing those interchangable parts. The fact that Ford maintained complete control of the operation and insisted on simplicity was a large part of his success. He also paid somewhat better and was able to always have people waiting at his door to be overworked. He brought outsourcing to him as probably the majority of the assembly line crews were foreign born and spoke limited English.