[True tales from the trenches]
"Patch it until it's robust"
By Eric Hartwell -- Saturday, March 12, 2005
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 realized 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.
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, sold the company to a group of investors, and retired on the proceeds.
Moral: Make sure you understand the business model before you think about the software.