How to win the Indy 500
Quick .. who won the Indianapolis 500 this year? Andretti? Castroneves?
Penske?
Actually, the real winner 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, so it took Honda just 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.
Honda won the Indy using the same technique that it's been using to eviscerate the American auto industry over the past five decades ... it 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 reliability.
How to lose at software development
The software industry today resembles pre-assembly-line car manufacture. Small groups of craftsmen build apps pretty much any way they wish, often with little or no systematic guiding strategy. With time and ever-changing staff, applications become more complicated and unreliable. Employers and consumers pay the price in the form of high development and maintenance costs.
In a typical development the schema design is done by a database guy who is obsessed with micro-optimization of individual tables. He fusses over minimizing table size and deciding things like which tables should get synthetic keys or status fields. The result is a hodgepodge of table designs, all within the same app.
Then we bring in the app guy to design the data layer. He's already stuck with an inconsistent schema, and he's so accustomed to this that he doesn't realize that it's a bad idea. The app guy must now contemplate the individual design of each table when writing the code to access it. Does it have status fields? Maybe. This one has a synthetic key, that one has a business key, and a third one has no primary key at all. So he creates a ton of hand-written custom code, all of which must be maintained throughout the life of the project. Or he decides to use an ORM such as Hibernate, which has a 900-page book for a manual and requires the app guy to supply perhaps thousands of lines of "code" written in non-type-checked XML.
At the end of the day, neither the database guy nor the app guy realizes the opportunities that were missed. Could we have built or used a tiny, efficient ORM if all the tables had had the same sort of primary key? Could we have audited the entire app if every table had status fields? Would the long-term cost of maintaining this app be dramatically reduced if there were consistency throughout? Unfortunately nobody gets paid to ask or answer these questions so nobody does.
The automotive craftsmen who micro-optimized every screw in every panel of every car they built thought they were doing everyone a big favor. To suggest that there was another way - that cars could be fantastically improved and cost-reduced through consistent systemic design - was laughable. Only after Henry Ford decimated his competitors did such ideas seem self-evident.
A coming revolution?
The world of software development will change radically once somebody starts building applications in a drastically more consistent way. We can and must have a revolution similar to the assembly line in auto manufacture.
In this article series I suggest a specific solution - one that you can start using immediately upon your next new software project, hopefully producing immediate results. The objective here is to produce small to medium database-based applications in which the vast majority of code is already written or generated for you, so that your only worry is to actually solve the business problem at hand. But these benefits will come at a price. For perhaps the first time ever, you'll be required to dramatically reduce the variations in the way
you design your schema and software. The main point of this approach is not merely the use of libraries and code generators (which you've no doubt seen before) but gaining extraordinary additional benefits by placing extraordinary restrictions on design.
Sounds unpalatable? Probably most of Henry Ford's craftsmen didn't like the assembly line either. The reward? If you stick with the series, I will ultimately provide you with both the methodology and all the code you need to make yourself potentially many times more efficient than you are today.
Rapid Application Prototype
We avoid reinventing the wheel by starting with an application prototype that already defines the structure of essentially any database-based application. The Rapid Application Prototype (RAP) uses a four-tier
model:
RAP comes with a database preprocessor that helps you generate
databases where every table has the same primary key design and the same set of
status fields:
RAP also has a Database Generator that automatically creates all the CRUD
code for both your database and your data layer:
RAP also has an extraordinarily simple ORM that requires almost no user
manual. And finally, RAP comes with templates for designing your Business Rules
and User Interfaces for a high degree of consistency and a minimum of code.
Get started by downloading and running RAP
To run the RAP demo, which is the basis of this entire article series, you
will need the following:
- Visual Studio 2008 or later
- .NET 3.5 or later
- and SQL Server 2005 or 2005 Express or later
- Microsoft Word 2003 or later (to read the instructions that come with
the download)
That's all! Start by downloading the
(RAP). Follow the downloading instructions
at the link. The download itself contains an Instructions document which will
guide you through the steps. You'll need about a half an hour to go through the
whole thing.
You can walk through the entire demo yourself without reading any further
articles. However if you want to really get into a discussion of how this
package works and what it can do for you, look out for the next article in this
series.
The Series
This is part of a series that examines the RAP application development system and a philosophy that believes in more standardization for both our database development and application organization.
