|
David Eddy describes a conversion task he performed as a team member in the mid-1980's. This was just for fixing code -- not analysis, not planning, not testing.
This was nothing, compared to a y2k repair.
This appears on Werstergaard's site.
* * * * * *
In 1985 I had the distinct pleasure of doing the only major system conversion effort of my professional programming career. . . .
Large conversions are typically done in a series of successive steps. While the ultimate objective is to move from A to E, it is often impossible to get directly between these two points, so the work is done in small increments: A to B, B to C, C to D, and finally D to E. This may sound complex (which it typically is), but you have to remember that when the objective is to replace the transmission on a front-wheel drive car, removing the engine is a necessary first step. It's simply not possible to get directly at the transmission. Software systems are the same as tightly designed machines where you normally have to slog through large amounts of disassembly work before getting to the point where the change is needed.
My task was quite straightforward. There were 450 programs (approximately 900,000 lines of code) that needed to be inspected, some dead code removed, a specific number calculated and inserted where a large general number had been before and other quite simple, mechanical tweaks. There was a maximum of sixteen changes that I had to potentially make to each program. . . .
My task was simply to make the changes (largely involving removing unused code, which in fact made this a very dangerous undertaking) and recompile the program. There was no, repeat NO testing.
This was mind numbingly repetitive work. On my single most productive day I was able to plow through just twelve programs. Normally I did fewer. By the end of each day I was mentally exhausted. . . .
Oh... and I left out the tiny detail that these 450 programs were actually just variations of three core programs. The fact that I'd written a sizeable number of them three years earlier helped too. Bottom line: I had the odds seriously stacked in my favor.
Y2K efforts will typically be working with decades old code and with programmers and managers who are completely unfamiliar with both the code and the systems. Need I lay out in black and white what these Y2K projects are confronting?
Are we having fun yet?
|