© 2003 Gerald M. Weinberg, www.geraldmweinberg.com
P.T. BARNUM said there’s a sucker born every minute, but Barnum was a conservative estimator — or else he didn’t know any IT managers. For more than 45 years now, I’ve watched an endless stream of technical “solutions” being promoted, sold, and quickly put on the shelf and forgotten.
Come to think of it, forgetting these “solutions” is not such a bad result. As someone once said: “A problem is the solution to the previous problem.” At least forgotten solutions don’t become bigger problem than they were supposed to solve.
Remember COBOL? What was it supposed to solve?
As Jean Sammet recalls in her History of Programming Languages, the users for whom COBOL was designed were two subclasses of those people concerned with business data processing problems.
One is the relatively inexperienced programmer for whom the naturalness of COBOL would be an asset, while the other type of user would be essentially anyone who had not written the program initially.
Little solutions
In other words, the readability of COBOL would provide documentation to all who might wish to examine the programs, including supervisory or management personnel. Little attempt was made to cater for the professional programmer.
I have clients today who are maintaining, with professional programmers, tens of millions of lines of COBOL code — and no supervisory or management personnel would dare to look at a single line, let alone change one.
COBOL solved some little problems, but left us with a much bigger one. Because these organizations are busy chipping away at the incredible mountain of maintenance, new development work of organizations falls behind.
Like addicts deprived of their drugs, the customers are eager for a “quick fix,” and ready to deal with any pusher. One quick fix is called “rapid prototyping.” Almost all of the “rapid prototyping” I’ve so far seen hasn’t been all that rapid, but that doesn’t matter, because it hasn’t been prototyping either.
I know that statement will bring letters from a hundred vendors agreeing with me – except as far as their product is concerned. But that’s not the battle I want to fight. Nor am I concerned that where prototyping works, it often works backwards. In building airplanes, for example, a prototype often leads to a higher rate of failure in the final version because the prototype makes the builders overly ambitious about the successor.
But let’s put these little quibbles aside and assume that everyone’s rapid prototyping system is both rapid and prototyping. Let’s grant that they work (after all, COBOL worked) and contemplate some of the consequences.
Santayana said that those who failed to study history were condemned to repeat it. I suggest we study the history of that earlier rapid prototyping language, COBOL, so perhaps we won’t all repeat it.
Although many today consider COBOL a failure, objective analysis says it was a great success. If it hadnt been a success, we wouldnt have billions of lines of COBOL code to maintain.
Here is a riddle: How do you accumulate a billion lines of COBOL code? Answer: one line at a time. In most cases, thats literally true, because very few of those billions of lines consist of original code. Over the years, as requirements changed, the COBOL programs have changed. Studies indicate that in a mature COBOL program, there have been three lines written for every one that remains in the code.
It took many programmers many years to accumulate those billions of lines, one line at a time. But we’re lucky, because now that we can program so much more rapidly, we won’t have to wait as long to accumulate our mountain of rapid prototype code.
In fact, now that we’ll eliminate the professional programmer, we’re going to have 100 times as many people developing prototypes. It took us half a century to get into the COBOL mess, but with rapid prototyping we can surpass that in a few weeks.
It’s not just the volume of COBOL code that causes the huge maintenance effort. Volume must be multiplied by a quality factor, because low quality code takes more effort to maintain. Yes, I know rapid prototyping languages are supposed to produce more readable code — but have you looked at any? Have you seen what happens after the users have made a few changes?
Lessons of history
History teaches us that when the users do actually make those changes, their ambition quickly outstrips their skill and the capacity of their language. At this point, they turn to the more experienced — the professional programmers who already are buried in COBOL code.
Again from history, we know that the more different people using code or data, the more constraints there are when it comes time to change. The amount of constraint makes each change more difficult, so a constraint factor must be added to the maintenance effort equation.
There may be some hope of controlling all this, but history teaches that most IT managers are going to go into a dopey daze in the sand while this quick fix enters the bloodstream of their organization. They can look forward to more maintenance, more difficult maintenance, done under greater constraints, with greater shortages of professional staff. Because they’re in a dopey daze, however, they won’t be looking forward at all.
The only people who can resist a quick fix are those that are not addicts. The only organizations that can avoid turning the maintenance solution into a maintenance trap are those that already have their maintenance under control. But that takes good management, for which there is no quick fix.
The moral of this story for my readers: Don’t despair of these hard times! There will always be enough work for those who are willing to slowly fix those quick fixes.
