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 five-digit odometers.

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.