AAArrrggghhh Legacy Code

Recently, I've been working on what is probably the "Ultimate" legacy/Brownfield application. It's a VERY important application for our business, or WAS, but the users are starting to find other ways to do their job. The problem is that the application in question is VERY hard to maintain, and management does not want to risk making any "non critical" changes. It's the classic "Big Ball of Mud" design.

Now no matter HOW many time's I've read Michael Feather's Working Effectively with Legacy Code, I can can never quite figure out how to make it work in this case. There are almost no seams to exploit. We have numerious routines that have a Maintenance Complexity in the 2000 to 3000 range. Of course these routines have no REASON to be that complex, it's just that previous programmers had a tendency to lump all sorts of things together that had nothing in common except that they needed to execute at the same time.

DRY? They never heard of it
The classes are just mirrors of database tables, and if a calculation needs to be done on a class or collection, the routine is usually inline in a form event, with "other" code mixed in.

I do find RefactorPro! to be a very useful tool, but even with automated tools, I have to take huge risks, just to get the code to the point I can start putting test harnesses on it.

Anyone else have to maintain a probram like this? The goal here is to get the application maintainable enough that I can start to add features to retain/regain our internal user base

A Basic Class Design Lesson

Hi Gang,
I'm going through some OLD code today, probably written before classes, but looking at it, I realized it might be a good class design lesson for those not used to writing classes.

The code was in a form, and was actually used multiple times - which by itself says the code should be in a function - code has been changed slightly to obscure the exact nature for my blog, and is in Visual Basic 6.0, but the lesson works for any Object based language

If Left(instanceOfClass.pollclose, 2) > 12 Then
objGrid.Text = (CInt(Left(instanceOfClass.closingTime, 2)) - 12) & ":" & Right(instanceOfClass.closingTime, 2)
Else
objGrid.Text = Left(instanceOfClass.closingTime, 2) & ":" & Right(instanceOfClass.closingTime, 2)
End If

OK (again, VB6 syntax) you could say:

Private Function formatClosingTime(byval theTime as string) as string
If Left(theTime, 2) > 12 Then
formatClosingTime = (CInt(Left(theTime, 2)) - 12) & ":" & Right(theTime, 2)
Else
formatClosingTime = Left(theTime, 2) & ":" & Right(theTime, 2)
End If
end Function

and put that in the form

Which would make the call in the form

objGrid.Text = formatClosingTime(instanceOfClass.closingTime)

- it's ok, and a heck of a LOT better than it was (remember, it's used multiple places - the Don't Repeat Yourself (DRY) concept comes in here)

BUT - that's NOT where the function should really be. What we do is add a Property to the class

Public Function formattedClosingTime() as string
If Left(me.closingTime, 2) > 12 Then
formattedClosingTime = (CInt(Left(me.closingTime, 2)) - 12) & ":" & Right(me.closingTime, 2)
Else
formattedClosingTime = Left(me.closingTime, 2) & ":" & Right(me.closingTime, 2)
End If
End Function

Now, this reduces the code in the form to:

objGrid.Text = instanceOfClass.formattedClosingTime

Isn't that better? The class is taking care of itself. Ahhhh