Saturday, March 12, 2005
	10:32:13 AM   On Error Resume Next I was instructed to fix a problem that a "star" programmer had discovered with my code. Apparently his VBScript routine was working fine, but he was calling my COM component's functions and they were corrupting the database. Imagine my joy when I started to trace through his code: Function WorksFine(EmployeeID) On Error Resume Next EmployeeRecord = LoadEmployeeData(EmployeeID) On Error Resume Next Calculate(EmployeeRecord) On Error Resume Next SaveEmployeeData(EmployeeRecord) WorksFine = SUCCESS End Function As you might expect, sometimes the Calculate function would fail and return one of its many documented error codes -- such as, for instance, when the LoadEmployeeData call failed and returned one of its many documented error codes. What you might not expect was that sometimes the EmployeeRecord object had enough valid data left over from the previous transaction that the SaveEmployeeData call would actually succeed in trashing some unrelated employee's record, before returning with or without one of its many documented error codes. The other programmer was quite upset when I put error handling into his routine. It turned out he had written it this way deliberately so he didn't need to write an error handler. This was how he achieved the high productivity that made him a "star" programmer. Moral: You get what you reward. [True tales from the trenches]   9:13:03 AM   "Patch it until it's robust" After months of panic mode, we finally managed to ship a functional port of a legacy program. The horrible hash of years-old FORTRAN code was impossible to decode, let alone fix, but we finally got it to run by turning off all execution error trapping. While I was recovering, I took two weeks off my regular job as team leader to do a thorough code review. We knew the program didn't work too well (when it worked at all), but we weren't sure why. It turned out that not only did the program rely on overwriting past the end of one array into another (which we already knew), but that it didn't implement its core algorithms correctly. The results were more consistent than random numbers, but only a little more useful. I concluded that the only way the program could be made to work was with a complete rewrite, which would take 4-6 calendar weeks. I explained the situation at our next project meeting. The boss (and sole owner of the company) explained in turn that we'd already made a number of sales, and we couldn't delay delivery for merely technical reasons. When I reminded him that the program rarely ran without crashing, that the results were wrong, and that the code was unfixable, he reminded me that the top priority was to eliminate crashes during demos. Finally, he concluded, "So it's settled - we'll patch it until it's robust". ... Not too long after that my immediate boss complained that I wasn't showing the proper team spirit -- "We've noticed you've started taking Sunday afternoons off ... is this likely to continue?" Well, yes. Soon after that I left the company. The remainder of the development team beavered away putting patches on the patches. Finally, a year later, they got up the nerve to tell the boss the program really needed a complete rewrite before it could work. Faced with the inevitable, the boss laid off the entire programming staff. Instead, he boosted the marketing effort -- and, finally, sold the company to a group of investors. Moral: Make sure you understand the business model before you think about the software. [True tales from the trenches]

© Copyright 2005 Eric Hartwell. Last update: 4/2/2005; 9:15:22 PM. This theme is based on the SoundWaves (blue) Manila theme.