Sunday, October 11, 2009

How bad is too bad?

I have been assigned the task of updating a program that isn’t terribly well designed.

How deep do I dive in trying to fix this program? Do I take all of the inappropriate code from the Form Classes and move them into Business Classes? Do I get rid of all the SQL queries in code? Do I tear the whole thing to shreds and start over with my brilliantly planned super object oriented design applying all 23 GoF design patterns? My inner geek screams yes, Yes, YES! But according to Joel Spolsky, rewriting software just to do it can be the biggest mistake “you” can make. (

I mean, the program basically works. If the world around the program wasn’t changing, it could probably go unchanged. But we’re replacing one system that this program talks to and replacing it with another one.

Looking at the code, I would date the program to around the 2003 timeframe with stuff added later as the program evolved. I see:

  • Int32 in place of int, String in place of string, etc. (I remember reading and hearing experts recommending that practice in the early days of .NET)

  • Long unstructured functions in the form class. Sort of like VB6 in C#, we know that a lot of that went on in the early 0's.

  • There is some object orientation grafted on to the edges of the program but the core is pretty old fashioned pre-OO .NET 1.0 code.

  • Uses finally in places where rational modern C# coders would use using.

So it isn’t wonderful code, but, for the most part, it works. But like any spoiled brat, I just wanna do it. Why: just because.

The program was written in the ancient times of yore (5 years ago). When .NET first came out, OO was just starting to catch on in the mainstream. Right now I am hearing rumors that the next big thing is going to be Functional programming; the justification is that it is easier to parallelize so elements of the Functional Fad will probably stick around for the long term. What will my elegant OO code look like to the Functional masters of the future?