I couldn't talk to users and they wouldn't give me a staff. But I got the job done anyway. [ We need your IT horror stories! Submit your wildest tales at http://weblog.infoworld.com/offtherecord/ ] Back in the late 80's, I was a Cobol/CICS programmer at a Fortune 500 company. My code was stable and efficient if not elegant. I thought I was doing good work and everyone seemed happy with my code. It was always on- I couldn’t talk to users and they wouldn’t give me a staff. But I got the job done anyway. [ We need your IT horror stories! Submit your wildest tales at http://weblog.infoworld.com/offtherecord/ ]Back in the late 80’s, I was a Cobol/CICS programmer at a Fortune 500 company. My code was stable and efficient if not elegant. I thought I was doing good work and everyone seemed happy with my code. It was always on-time or early. My reviews were always excellent. Jump forward a few years to a new project I’d been given, my first as lead. I was to rewrite from scratch a very old program that ran for hours. Requests gathered from the users indicated that about a dozen CICS programs and six or so batch jobs would be required. It was supposed to take one analyst and three programmers six months to fully analyze, spec, code, test, tune and implement the system. Then the problems started. Management felt I spent too much time talking to the end-users, implying that any time spent talking to them was too much. According to my supervisor, I should have gotten all the information I needed from the description of the project, despite the excellent feedback I got from users. Meanwhile, of course, the end-users were tickled to get a system they could really use. The prototype—the first ever done at this company—was a big hit. I had 100 percent user buy-in on my prototype, but management still thought I was wasting valuable time and said so often. Resources were not provided as management’s faith in me seeped away. Total resources allocated to this project after the analysis: me. Because I was just a programmer, I couldn’t have people working for me. More than likely, however, it was retribution for my attitude toward user input and approval. The project went smoothly despite it being a one-person show, and it was turning into a labor of vindication. I had no staff that management could take away from the project so they opted to conduct a stealth code review instead. My supervisor checked the source library and looked over my code without my knowledge. As a result, my code was deemed to be “too complicated” for others to maintain, despite the fact that it was very tight, very fast, self-documented Cobol. When I balked at making wholesale changes to code that was already tested, my supervisor referred me to the manager. When I resisted the time-consuming task with the manager, I had a meeting with the VP, who politely indicated that I would have to change my code or else. Each of a dozen programs ballooned in size to more than triple their original size. Rather than let management know they were working me to death, I took the code home and edited it on my home computer until the wee hours of the morning. I made macros for most of it. The next morning I uploaded it to the system, compiled, and continued my day. I did everything I could to keep the code fast and fully functional. My users largely agreed I had succeeded. I still managed to complete the task alone and on-time. The first live test of the new production process ran in a mere fraction of the time the original process took. My supervisor cheerfully noted that it must have failed — it didn’t run long enough. We both examined the output and to my joy and her horror, it worked perfectly. I never even got so much as a “thank you” or a “good job” from anyone except the end-users. The strain this placed on my relationship with my supervisor and manager was nearly unbearable and affected my next review. I was branded, via the watercooler network, as not being a team player. I sought and was granted a transfer to a different chain of command. It was either that or look for other employment. The new position began well. My new supervisor was pleased with my work and reviews again were glowing. Then the troubles came. The company hit financial problems due to the run-up of debt due to the CEO’s poor judgment, bungled buy-outs, and the like. Spending was cut and projects were canceled. Stocks tumbled to one-tenth of record highs in a matter of weeks. Then heads began to roll. And guess whose heads they were? My old supervisor, manager, and VP! I’m still here and they are long gone, ignoring users and promoting bloated code at their new jobs, no doubt. Data Management