In my career, I have been in organizations where the powers-that-be felt that because of the nature of their work, programmers in maintenance were lower on the food chain than programmers in development efforts. Very stupid attitude, but there it was.

I don't know if this is a common problem today and whether this has complicated Y2K remediation efforts.

-- Peter Errington (petere@ricochet.net), July 25, 1999

Answers

A few years ago, I was doing maintenance on a legacy batch system when I wasn't working on a on-line system. When the Board of Directors decided to do something about Y2K, they made an executive level decision to contract the work on the batch system out. They congratulated themselves because they managed to hire one of the Indian firms (cheap labor). The online system that I worked on was being scrapped for a newer one, that was supposed to be in place in 1992, but wasn't.

The project was managed without very much input from the maintenance programmers. It would have made sense to use Y2K as an opportunity to go through the code and optimize it, but the Indians took a very mechanical approach. They were told to expand all dates, so they expanded all dates and expanded all record sizes, even where there was adequate FILLER in the records. This meant changing all JCL, which created a major job keeping track of changes.

I quit before this project was completed and went to work for a firm with a Y2K remediation tool, so I don't know how it turned out. (The last I heard, this organization was on the verge of going out of business in any case.) I know that if the Indians had not been hired and the maintenance programmers had done it without expanding all the dates, the project would have been much simpler. Most of the complicated subsystems used a date field as an identifier only, and never compared dates in two different years, so they could have been preserved with minimal changes and a bridge to other systems, which would have saved lots of testing time.

Just after I was hired in my new job, the market for Y2K work went into a slump, and no one could figure out what was going on, because the metrics showed that there were X million lines of COBOL that needed to be remediated, and yet firms set up to do Y2K were going out of business. We were having trouble selling our tool, because the consulting companies didn't have enough work, so they didn't need an automated tool. What appears to have happened was that maintenance programmers were given the job of fixing Y2K, and they did it in their spare time - meaning it was either more efficient or sloppy and missed a lot. Or both.

In one case, we sold our tool to a telecommunications company with a bureaucratic structure like my old employer. There was a Y2K team consisting of consultants, who were not allowed to talk to the regular programmers. They decided on their own to expand all date fields. When the delivered the remediated code, the regular programmers looked at it and decided that various dates should not be expanded, so they threw that work out. (Our tool would have windowed the dates automatically, but they missed that opportunity.)

This is long enough. Companies that do not use their maintenance progammers well have a general management problem; Y2K is just a symptom.

-- kermit (colourmegreen@hotmail.com), July 27, 1999.