Today, I attended the Enterprise Software Development Conference (DISCLOSURE: a conference run by SD Times parent company, BZMedia). This informative day of talks from the likes of Ken Pugh, David Intersimone, and Robert C. Martin lead me to one conclusion: there is some terrible code out there, and you, loyal readers, are the poor souls who are paid to clean it up. It is a difficult and thankless job, but that's why there are IDEs and static analysis tools. With enough time and effort, you can understand that 25 year old billing system, and you can make it work again.

In one session, an attendee told the story of his work with a large company that was having trouble with its billing system. To rectify the problem, they had been buying larger and larger Oracle licenses. It turned out that the code running their billing system never closed database connections. Ever. Four lines of code later, things were much better.

But as all of you reading this know by now, being an enterprise developer is rarely about writing perfectly clean, fresh code. All too often it's about connecting pipes, and in the very worst of times, forensics. 

Now, we know that when you're writing something anew, your team produces shining examples of modular, reusable, well commented code. But every company has bad code somewhere. Hidden in a dark office, running an ancient database on a machine that uses VHS tapes for backups.

And those are the tough problems that cause the most pain, yet they are terrifying to deal with on a code level. It's always a tough decision to start from scratch, and many times, you simply can't due to business constraints. Sometimes those problem applications are written in some arcane language none of your team understands. Other times, the source code was obviously written by people who hated white space and knew nothing about comments. You've all got your problem child applications.

ESDC's speakers offered a lot of advice, both on how to fix rotten code, and how to avoid the mistakes that lead to said bad code. David Intersimone, in particular, discussed strategies for dealing with nasty old code bases (He recommends a vigorous application of IDEs, refactoring, and analytics). There were many other topics discussed, including virtualization, and iPhones, but I got the sense from the attendees that this was the one topic with which they could all sympathize.

It is for this reason that I propose a new type of college course for anyone who wants a career in business programming: the "Fix it" course.

This class would require no in-lab time, no teacher. Just one big blob of horrible code, preferably in COBOL or some other more ancient dialect. The code would only run on a slow machine hidden in a basement somewhere, and accessible only through telnet. And it's broken. Students are then given one full semester to fix it. I think we can all agree this would be of great value to young programers, and prepare them well for the world ahead. Especially if the code contained no comments and no line breaks.