Are We There Yet?

The future for IT is the same as it was for agriculture in the 19th century and manufacturing in the 20th century. There will be more output per person, but fewer people total in the field. And the world will be better off as a whole.

Let's be honest about the way we built systems until recently. We acted as if we had never done this before and would never do it again. Nobody thought to make the system maintainable while they were writing it. Someone else did maintenance, at a much later time, and it wasn't the concern of the developers. The important thing for the developers was to hit their budgets and deadlines with something good enough to work for about a year.

Problems Big and Small

If you could look at a graph of problems, there is a large spike when a system is installed. The fact is users dislike reading manuals as much as programmers dislike writing them. These problems are solved with training and a little RTFM (read the flaming manual). The real problems show up as a smaller bump at the end of the first year.

I am pulling up the first year as a "magic number" because year-end reports are the first time that someone has to look at all the data in the aggregate instead of one transaction at a time. This is when you find out that security was tacked on after the fact, not built in. (If you don't believe that, do a Google on Microsoft security holes.) This is when you find out that someone invented his own encoding scheme and you cannot interface to the rest of the company data via some industry standard conventions. This is when you find out that the reports from your application don't match the reports from another application.

In short, it's like going for your annual physical at my age.

Past and Present

In fairness to the trade, the structured programming revolution in the 1970s and object-oriented techniques did a lot for software quality at the code level. Programs written today are, on the whole, easier to maintain and to port to new platforms than those written in the languages of the past. But low-level software quality is not the same as systems quality. How easy is it to move an entire system from one platform to another? How easy is it to change the business rules?

The popularity of Java among application programmers comes from its claim that you can write it once and run it anywhere. Contrast this to the attitude you find in many database programmers who think proprietary, nonportable features are good things. Anytime I hear "I'll never have to port this code" all I can reply is "Maybe not, but some poor schmuck will!"

But how do you move an entire system? The only solution I can see is to have a high-level abstract model that is formal enough to be manipulated — the model-driven architecture approach. The goal is to be able to develop and verify a model for an application, tell the system what the target platforms are, then push a button and have all or most of the application fall out in your lap.

For example, I could specify that I want an IMS database and Cobol application code or I want some flavor of SQL and Java. It does not matter what the target is; the same model can be used to generate any implementation of the system. In effect, I save the blueprints for the next construction job instead of throwing them away each time. This is pretty powerful.

But the real power comes from being able go to the model and make high-level changes that will cascade consistently down to the implementations. I am talking about system-level changes, such as adding audit trails and security or changing accounting methods. Even today, we try to make such changes from the bottom up, one code module at a time. You never quite find all the changes the first time. You never quite change them all the same way.

Are we there yet? No, but we are getting closer and closer.

Joe Celko [[email protected]] is vice president of RDBMS at North Face Learning in Salt Lake City and author of five books on SQL.