Coma Crawl

I’ll be the first to admit that I’m a bit on the anal-retentive side. Ok, a lot. And nowhere more so than in my source code. I like my code tidy. I break my code into logical, easy-to-use units. I give modules meaningful names. I get rid of unused variables, methods, and units. I don’t leave test versions of units laying around. If you’re handed code I wrote, you can know with certainty that it contains what it needs, and nothing that it doesn’t.

You see where this is heading, don’t you?

The code base that we were handed a year ago was, it goes without saying, a bit sloppy. Just a tiny bit. There were 1050 Pascal source files, comprising over 660,000 lines of code, or about 380,000 actual code statements (lines of code that aren’t comments or white space).

There was some overall structure to it, though it strayed from the plan in a lot of places. As we started digging in and getting familiar, we began to find files that simply weren’t used. And plenty of unused pieces of code in files that were used. And we started cleaning it up. Test versions, backups, copies of copies, duplicates, programs that never got past the crude UI phase.  Lots. Of. Junk.

Today, the system has been whittled down to ‘only’ 640 Pascal files; 450,000 lines; 270,000 statements. Or put another way, depending on which metric you use we have been able to delete between 30% and 40% of the code we were given, as it was never, ever used. More, really, once you take into consideration all the new code we’ve written – that’s included in the current totals.

About once a week I come across yet another unused file or method and get rid of it. I have a nagging suspicion that we’ll still be finding them a year from now.

How in the hell does someone let their code base get that messed up? Forget my anal-retentive nature – a basic sense of pride in a job well done should prohibit that sort of sloppiness. Or hell, just the necessity of maintaining the code should be enough to encourage at least some neatness.

The program is written in Delphi. Which is why I was hired – I’m a Delphi guy, and before that I was a Turbo Pascal guy. It is the One True Language as far as I’m concerned.

Did I say program? Sorry, I meant programs. Plural. This system is a collection of over 50 different executables. A couple run client side, the rest on the server. When I first realized this, my brain seized up for a few minutes. Now, after working with it for a year, I have to agree it was probably the best approach to the design.

The software is essentially a vertical market document management system. Some users create the documents, other users proof them, still others sign off on them. Different kinds of documents move throughout the system in different ways, going from queue to queue based on configurable rules. Complete documents get assembled in various ways depending on their destination – email, faxing, local printing, remote printing, etc. It’s terribly complex, by necessity. Having various operations handled by different programs means that if one part gets hung up, the rest of it will generally continue to function.

Fifty programs might, perhaps, be just a bit excessive. From my perspective, coming in and taking over a system that someone else designed, it can be very difficult to determine which of the individual programs does what, or to track down where a bug is occurring.

All of these programs share a lot of common code, which is both a blessing and a curse. On the plus side, when you make a change in a common unit, that change will flow through to all the programs that use it. But on the minus side, when you make a change in a common unit, that change will flow through to all the programs that use it. In theory the common code is a good idea as it simplifies maintenance. In practice, so many things have been poorly hacked into the code over the years that the shared code often becomes a liability, as it makes things extremely unpredictable.

For example, you make a necessary change in Unit A to improve behavior in Program B. But Program C depends upon the code in Unit A to work a very specific way. Now suddenly Program C isn’t working right. Even worse, there is a lot of indirection (even misdirection) in this code, so we may not even know that Program C was making use of the part of Unit A we changed. Until, of course, the customers come yelling at us.

We knew from the start that the code was complex. The deeper we dig, the more we discover just how complex. The chain of references and dependencies between and through unit after unit is breath-taking.

I’m one of the New Guys. When the owner of a one-man software business sells his company so he can retire, and programmers are hired to come in and take his place, they’re the New Guys. Or perhaps you’ve heard them referred to as suckers, victims, chumps, patsies, or fools. Yeah, those work too, but I’ll stick with ‘new guys’. The other names all strike a bit too close to home.

Call the old guy ‘Buck’. As usually happens in cases like this, Buck spent a couple of months showing us three new guys around the system, giving us the broad overview. Of course, the only way to really learn a codebase is to dig in and start breaking changing things. So that’s what we’ve been doing for about a year now.

Along the way we’ve seen, debugged, worked around, fixed, and occasionally been the source of, a variety of absurdities, brilliance, victories, failures and goofiness.

Don’t get me wrong – the product is very good, despite a lot of weirdness in the code. So it’s not a death march. We’re not heading inexorably to our programmatic doom. We’ve got a decent, if not always solid, base to work from. We’re struggling, sure, but we’re slowly bringing new life into the system.

It’s not a death march. It’s a coma crawl.