(1) when your volume goes way up,

(2) when you hit milestones like the one hundred thousandth customer,

(3) when you make the first big set of enhancements.

All systems have bugs and problems -- you never get the last bug out of a big system -- but they're a little like Near Earth Asteroids; as long as they're floating around in their standard orbits they're not too dangerous, but if you jostle them around a bit, no telling what might happen. Big volume increases and milestones jostle systems around and may bring some old bugs out of hiding. Maybe not. Like the asteroids, maybe they won't hit the Earth for a million years, or maybe one will blast you and the town you live in out of existance tomorrow.

Volume and milestones give you an idea about the "bugginess" of the system. Enhancements tell you about the quality of the code. If simple-sounding changes seem to take inordinate amounts of time, it could mean that the changes weren't simple after all, or it could mean that the system is badly designed and/or badly written or that you're not the wonderful data processor you thought you were, or it could mean that the system is badly designed and/or badly written.

Some systems are just "born to lose." Or, at least, born with no chance of winning. The identifying characteristic of born-to-lose systems is pieces of code that work fine when the volume is low, but become increasingly slow or cumbersome or unwieldy as the volume increases. In other words, as long as the system isn't a big success, everything works fine, but when your wonderful new system starts attracting new business and the volumes go way up, it starts to turn a bit brown and smelly. Listings are a good example of the born-to-lose syndrome. You decide that, instead of building a screen inquiry function, you'll give some of the users listings of the data they need. "It's only a couple hundred pages. They can just put it on a corner of their desk and page through it." Which is true until the volume goes up by a factor of ten and the guy from the computer center starts coming in with ten boxes of paper on a hand truck.

But the real killers in the born-to-lose area aren't external processes like listings and manual data entry steps -- you can always rewrite those like Bill eventually did. The serious problems occur when the born-to-lose function is buried so deep in the system that changing it requires the data processing equivalent of open heart surgery. Let's say you're doing a payroll system for a small company and you decide to first collect time sheets from all the employees and then issue payroll checks. What could be wrong with that? Nothing if your company consists of three guys in a telephone booth, but if one of those guys is Bill Gates and the company starts turning into Microsoft, it'll become harder and harder to collect all those time sheets from all those people in different places with different lives and different agendas quickly enough to produce the payroll on time. You can treat this as a management problem and try to solve it by beating on your employees to get their time sheets in regardless of anything else that's happening in their life.

"I'm sorry to hear about your wife being kidnapped by a band of mountain gorillas, and the EPA not wanting to rescue her seems unfair, but would you mind filling out your time sheet before you leave on safari?"

Or you can treat it as a data processing problem and change the system so that the payroll always comes out on the first of the month and you make adjustments based on the prior month's time sheets. If you do that, the born-to-lose function -- requiring that all time sheets be in before payroll is issued -- may require a substantial rewrite.

Mr Berra said, It ain't over 'til it's over." What he forgot to mention was that some things aren't over for a long time.