Programming in the box

Ok, my blog about turning parts of a system (EJB in this case) on and off is nagging at me.

A lot of us like to tinker. And we like to express that tinkering in the form of writing efficient systems. Myself, when I was going through a CS degree, used to pride myself on efficiency. "I can write that in 20% less code and get 10% better performance than anyone is my class."

Obnoxious, eh?

Tinkering gets in the way of productivity and robustness. When Ford designs a new car, they don't usually design a new battery from scratch. Or go to a 16 or 24 volt electrical system (though to do so would definitely solve some sound system problems). They reuse what they have. There is infrastructure that supports 12 volt cars.

Not all car companies work (or have worked) this way. Volvo had the reputation for artisan attention to quality, where a small team built each car from beginning to end, then moved to the next car. Volvo lost.

A lot of folks are worried about success of their company (read: keeping your job), or outsourcing (read: keeping your job). Productivity and "it works" are the way other folks (eg car companies) facing the same issues solved them. They build systems from components that are already designed, and use them as-is.

Dell is another example. Their model is to build systems out of industry-standard components. Unlike some larger companies that designed their own hard-drives, these folks used standard drives already on the shelf. Soooo, how many folks in HP's PC division are still there?

What all this is intended to add up to is: programming is in many respects no different from building other kinds of things. Writing from scratch, or tweaking and chopping and reforming existing components, isn't engineering. Engineering is about reusing existing components whose design properties are understood and proven, and changing only what needs to be changed to solve a problem, so you can predict the outcome (eg. time to market, bug frequency, etc). Repeatable process. The more variables you change, the less you can predict about what you'll get. And the less infrastructure you'll have around to support your product over the full lifecycle of its use.