More

Post #16,298 by gdaustin 11/3/01 12:02:00 AM Reply	More We have two Windows-based systems in our company which represent two of our four "core" businesses. I am currently working on the fifth and sixth "core" business, which we hope to have online early next year. The two new businesses are in Unix. There are already plans to replace 3 of our 4 "legacy" businesses with Java or Delphi replacements (we can run either Windows (Delphi) or Linux (Kylix)). They will be able to run on either Windows or Unix/Linux. The "last" business will probably just go away, because it isn't profitable. Our largest legacy moneymaker (a huge Windows kludge) was down twice last month, once with Nimda virus, and once with a programming bug. Each time, the client suffered through a multi-hour outage, on what we advertise to be an "almost realtime" system. The client visited us this week. The visit was primarily to handle how we were planning to achieve HIPAA compliance, but the outages came up in the conversation. The client brought a representative from a big 8 consulting firm. With the recent departure of the company's CIO, I am very concerned that the outages have put one of our "core" businesses at risk of being taken over by a big 8 consulting firm. I know how these consulting guys work and having them visit us was just the start of them pitching a project to replace us. Now, this Windows kludge was poorly designed, poorly coded, and is poorly monitored by our processing staff. And the second outage was due to several programming bugs in the code. The bugs weren't caught because the owner of the company had a single "senior" programmer develop the project and did not follow a process of code review and inspection for defects. This same error would have also caused the code to fail in Unix. The other outage was caused by the Nimda virus, something that definitely would NOT have happened, had we been on Unix. We are having code reviews now, but we haven't gone back and reviewed all the "legacy code". The problem is that a "legacy code review" would cut into our new projects, and the owner feels that we need to deliver these new projects for us to stay in business. Glen Austin
Post #16,330 by wharris2 11/3/01 9:14:45 AM Reply	Very typical We are having code reviews now, but we haven't gone back and reviewed all the "legacy code". The problem is that a "legacy code review" would cut into our new projects, and the owner feels that we need to deliver these new projects for us to stay in business. Been there, done that. :=( Actually, ten or fifteen years ago, I was the programmer behind a complete rewrite of what I guess you'd call a "core component". Took a really crufty program, reduced it to essentials, and rewrote from scratch. I suppose there are people who turn their noses up at such projects, but except for the "drop everything, we've got to do this" three month interruption (which, after all, can't have been that important since I don't remember much about it), it was a pretty interesting and rewarding project. Alas, since then I've met/encountered a lot of code that could have used the same treatment, but never got it. "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
Post #16,429 by static 11/4/01 5:14:05 AM Reply	Now that you mention it... ... I seem to recall doing the same on a small project. The hardest part was not insulting the previous programmer whose mindset was very very COBOL (but he'd written this in QuickBASIC). This was because he was my boss. Fortunately, he quickly accepted I was a rather better programmer than he. Hmm. I seem to recall a few more I did along the same lines. One I even did to myself! (Dial-in package around Banyan VINES; front-end program written in QuickBASIC for authenticating the user upfront before they connected to the server. Managed to re-write it in VINES' dial-up scripting language. Saved a few hundred K.) Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"

Welcome to IWETHEY!