Software archaeology

There are times that I think my job is the same as an archeologist. 

Rick touched on this a bit on his “Anatomy of a Software Bug” post (an excellent read, btw, if you haven’t already seen it).

Code, like people, gets old. And, just like old people, old code tends to be pretty brittle.

This is especially true after the original developer of the code has moved on to greener pastures and the remaining members of the team are left to maintain the code. Since they don’t always understand the details of the implementation, they’re not willing modify the code, for fear of breaking the code. But they’re still tasked with adding new features to the code, fixing bugs in the code, etc.

As a result, they tend to make their changes as small surgical changes that affect the component as little as possible. And the more these surgical changes add up, the more fragile the code gets.

As these changes build up, the code in the component starts to resemble a piece of conglomerate rock. The more people add onto the base, the more blobs of other rocks get added to the conglomerate.

When I work on the code like this, it sometimes feels like I’m an archaeologist digging through the layers of an ancient city – if you pay really close attention, you can see which developers wrote which portions of the code.

One of the clues I have to work with is the tab styles – different developers use different tabbing conventions, which is a clear clue. Similarly, different developers use different bracing styles or different naming conventions on variables.

I’ve been working in winmm.dll for the past several months, and it is a classic example of this. The base code is about fifteen years old, it was written for Windows 3.1. Over the years, it’s been ported to Win95, then ported to Windows NT, then ported to Win64. The code’s been tweaked, support for new technologies have been added (WDM, PnP), functionality’s been replaced (the current joystick logic is totally different from the original logic). So there’s been a lot of stuff added to the original core. But it’s all been bolted on piecemeal.

In addition, since the code was written, Microsoft as a whole has gotten a whole lot getter at software engineering – the coding standards and conventions that are standard today are orders of magnitude of what was done 15 years ago, so sometimes it’s painful to see the old code sometimes – as I’ve written before, back in the late 1980’s, code size was king, memory was expensive, so design decisions were made to favor techniques that reduced code size at the cost of code clarity.

By the way, this isn’t a dig on WINMM, or Microsoft’s coding – ANY sufficiently old piece of code will have these characteristics. I’m sure that you could perform the exact same archaeological analysis of any old piece of code and find the exact same kind of issues.