|
Comment: |
This is from Andrew Tobias' column. It's a letter from one of his readers.
* * * * * * *
"Here’s another Sixties programmer reporting in. I worked for a major insurance company, and back in the mid-1980s one of our major accounting systems started going crazy for selected policyholders, one at a time. After a few months, we were instructed to delve into the program and find out why accounting reports were no longer usable for these clients. Seems the system used a one-digit year. If the one-digit year code was 5 or greater, the previous policy year for the policyholder was assumed to begin in 197x; otherwise the date was assumed to be 198x. By 1985 the accounting years were containing 120 months of claims, not 12. What does Dan mean, ‘the documentation doesn’t match the programs.’ What documentation? We never got around to doing that; there was always another system to write. Back in the 1960s, programmers were scarce, and we didn’t waste our time writing documentation. Besides, that wasn’t any fun . . . we wanted to program. It scares me when any company says that they have the Y2K problem under control. What gets you in any system change is what you haven’t thought of, not what you’ve programmed and tested. I don’t think I’ve ever worked on any major system change when everything worked 100%, even after it was tested and tested and tested. And the ratio of complete failures to successes for new systems (i.e., when the whole system is junked rather than put into production) used to be about 1 in 6 (and not just for insurance systems, for all systems), so a total system rewrite may not solve it, either. I certainly hope that the ratio has improved recently. I’m glad I’m not a programmer in 1999; I’m sure their New Year won’t be happy."
|