« Behind the Headlines | Main | Prediction #12: Rise of the (virtual) machines »
Friday
Jan192007

Great Management Books: The Innovator's Dilemma, and The Godfather

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. -- Antoine de Saint-Exupery

I've always liked Clayton Christensen's book 'The Innovator's Dilemma' as a metaphor to explain product innovation and succession. To vastly oversimplify the main idea, companies get so good at "hammering" that everything: screws, rivets, staples, welds, etc. is either treated as a "nail" or crushed in favor of "nails."

Software is an industry that produces natural monopolies, and so for software The Innovator's Dilemma applies, not just to individual companies, but to the entire industry.

This makes things really hard for software developers today. Microsoft, with Windows started out as a system for non-networked individual devices, and has tried to expand all the way up to clustered 'mainframe' solutions. Enterprise Java started out trying to boil the ocean, boiled it, only to find that ocean-boiling solutions aren't of much use when all you want is a cup of hot water for soup. In trying to solve the same universe of problems, both the Microsoft and Java camps have adopted the same set of ills. One size doesn't fit all.

In this case of two increasingly over-engineered systems, I prefer openness, not because of what you can add, but because of what you can take away. The key ratio for software managers to watch I call the "overhead ratio" which is (Time spent on the solution the customer will pay for) / (Total time spent). The ideal solution would have a quick installation, rapid configuration, and rapid user iterations to a state of solution-ness that is "just right." The ideal development effort will spend all its time on "value-add" components, and none on "configuration."

Both Microsoft and Java development have a pretty onerous overhead ratio - getting all the components right takes an increasingly long time. As I've previously noted, I like 'virtual appliances', and the "Convention, not Configuration" mantra of Rails/Grails for just this reason.

But there's more to it that that, a notion that I'll posit as The Godfather's Law: "Technology components that reach a sufficient level of irritation are made to SIMPLY DISAPPEAR." Credit Mario Puzo with this:

"As soon as the Corleone Family set up their usual business liaison with the local police force they were informed of all such complaints and all crimes by professional criminals. In less than a year Long Beach became the most crime-free town of its size in the United States. Professional stickup artists and strong-arms received one warning not to ply their trade in the town. They were allowed one offense. When they committed a second they simply disappeared.*"

Software licensing is a headache? BING - SaaS.
MS Shop that doesn't run Linux? BANG - Virtual appliances.
No (MS) or overcomplicated (EJB) ORM? - BOOM - Hibernate.

...and so on. As the best software people are 'Lazy, Impatient, and Hubristic' (a description that also fit Sonny Corleone), no system of excessive overhead ratio will last long. One key to software success is to figure out when a paradigm is about to get "bumped off", and to move in on all the action when it happens.

There is a great opportunity for software development organizations who can surf the transition. The key is not in choosing the "next Java" or hot development environment, but in identifying all of the barriers to adoption and making them "simply disappear." Even if they might agree on nothing else, the two "C's" (Christensen and Corleone) would agree here.

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>