Quick .. who won the Indianapolis 500 last year? Marco Andretti? Dan Wheldon?
Ana Beatriz? Someone from Team Penske? Who was second? Third?
Actually, the real winner of the most famous American auto sport was the Honda Motor Company.
Since 2006 Honda has made all the engines in all 33 cars of every Indy
race, so no matter who wins, Honda wins. In 1994 Honda was new to Indy racing,
which means that it took Honda a mere 12 years to eliminate all competitors. Even more interesting is the
fact that prior to Honda's arrival, Indy
drivers had a greater chance of dropping out due to engine failure than from
crashing. Now the odds of engine failure are approximately zero, which means
that if you didn't finish, you probably crashed. In 2008, 2010 and 2011,
there were actually, literally zero race-day
engine failures at Indy.
Honda doesn't win by accident. It wins by design. Honda designs its cars
and engines using methods based upon the work of a little-known engineer named W. Edwards
Deming. Deming is the guy who taught the Japanese how to build automobiles that could
run for 200,000 miles without any major repairs at a time when US auto makers
were reveling in the joys of planned obsolescence and selling us cars with
So what is this big design secret that so few American managers seem to
know about? The central concept of Deming's quality engineering is this:
reduction of unnecessary variation
That's it. That's how the Japanese redefined the US auto industry. That's how
the world's manufacturing leaders, today now mostly overseas, rule the world
markets. And that is how someone else is probably going to eat your lunch unless
you get hip to the idea.
Honda wins the Indy every year because it long ago converted auto manufacture from art to science by
eliminating variation from its manufacturing
process. Honda auto parts are far more uniform than those of most competitors, giving Honda lower overall costs of manufacture, reduced need for
testing, and staggeringly higher overall reliability. While most car makers seek
out the cheapest parts suppliers, whom they will abandon at a
moment's notice for a cheaper part, Honda establishes long-term vendor
relationships in order to ensure consistency from part to part and year to year.
But uniform parts are just the beginning. Honda doesn't just design a car - it
designs entire systems to ensure production of the most staggeringly uniform
cars on the planet. Starting with the
most consistent parts in the business, Honda has assembly techniques to further ensure
that the small unavoidable variations in its parts cancel each other out as much as
possible, so that for example two rotating plates in a transmission will cancel
each other's imbalances to reduce destructive vibration.
So what does this have to do with software app development? Everything.
Despite all the hype to the contrary,
the central concept of quality app
development is the same as in every other engineering field.
The out-of-control software project is not a victim of unfortunate circumstance. Rather it is the
predictable result of a naive view of software development - namely that a
software "app" consists of nothing more than a collection of features that can
be strapped together any-which-way by any given set of programmers and expected to function properly.
But wait, you may be saying. Manufacturing involves the creation of thousands
of nearly identical items, whereas custom app development is simply done once.
How could there be a connection? Well the connection is that even a single
software application is almost certainly doing dozens of similar or identical
things throughout. If you have designed your app well, each such group of similar operations
is being performed by one central body of code -
minimizing the variation in how things are done throughout your app.
Creators of the tools that programmers use to build apps, such as Microsoft
for example, have spent years and millions building features into these tools
that allow programmers to achieve great levels of uniformity in their software
designs and implementation. There is a whole field of programming called "object
oriented design" that is dedicated entirely to the use of such features. There
are also whole segments of formal computer science ("state machine theory", for
example) that deal with producing code that simply cannot fail, i.e. where the
design is so intrinsically tied to the user's usage of the app that the app
simply cannot produce an unexpected result. These methods can collectively be
used to produce applications that are orders of magnitude easier to build
and maintain than most typical apps.
So why isn't the custom app business bathed in success? Why aren't we
experiencing a software version of Moore's Law, where the cost of app
development drops by a factor of two every 18 months? With hardware success so
predictable, why does the failure rate of software projects stubbornly remain
well above 50%? And in a world where the cost advantage in computer hardware
over the past 30 years is now about a billion-to-one, why are companies bleeding
themselves dry trying to develop custom apps?
Again the answer is simple. Although the tools already exist to remedy these
problems, few programmers are either trained or inclined to use them.
Furthermore the software industry is now awash in a set of "methodologies" that
actually discourage the practice of doing upfront design
(upfront design is essential for the successful use of these tools). And
finally, aggravating the problem even more is the increasing management tendency
to believe that we can staff software projects with ever-cheaper,
ever-more-junior programmers, much as the manufacturing industry has done.
Unfortunately this successful low-skill manufacturing paradigm just doesn't map well
into the ultra-high-skill field of software development.
In thirty-five years of software application development I have seen really
only one common thread underlying software project success, and that is
consistent design. Conversely, every project failure I've observed is
due to poor design, which is simply the absence of consistent design. The
destroyer of software projects is rampant variation - the app has 20 ways of
doing the same thing, replicated for each of the thousand things that the app is supposed
to do. You cannot throw enough money or staff at a poor design to make it work,
but that is precisely what thousands of companies are doing in desperation at
this very moment.
The next few articles will be dedicated to high-level explanations of the
core components of successful software development, including clear
illustrations of how each component directly affects your bottom line. Should
you as a CIO or software project manager take the time to become versed in such
technical detail? I think so. There was a time when an American manager could
get by with an MBA and a good golf game. Shoddy engineering didn't matter,
because the world would always buy from the world's only standing industrial
power. But today it seems that managers need to know a lot about what the people
beneath them are doing. Managers at Honda and Toyota and Hyundai tend to be line
workers who rose through the ranks, and who understand the engineering
challenges and company design philosophy very thoroughly. When Apple Computer
placed itself under the direction of a non-technical marketing star, it spent
the next decade losing market share Today, any CEO of a modern oil company who
is not following the latest developments in theoretical particle physics will
probably not be CEO for long.
I've seen CIOs and technical managers fiddling with their cell phones at
technical meetings. The message from that has always been clear to me. My
message is this: if you are not leading the technical discussion at your next meeting, perhaps
your job is not as secure as you might imagine.