Editorial Note: I originally wrote this post for the NDepend blog. Go check out the original here, at their site. If you like posts about static analysis, code quality, and architecture, head on over and check it out.
If you have a sadistic streak and manage a team of software developers, it’s probably high entertainment to dredge up some old, dusty piece of software and then to task them with maintaining it. If, on the other hand, you’re a normal human being and you’re asking this because it’s necessary for your business, you brace yourself. After all, this is legacy software, and the reaction of the team is likely to be quite predictable.
Alright, let’s take a look at this thing. Oh, man, look at that right there. A global variable. And — oh my god — there are dozens of these things. Who even wrote this? And, look at this over here. That’s the kind of idiotic, backward code that we used to have to write 20 years and 6 language versions ago when this code was current. But even when it was current, this code was horrible. This was obviously written by a trained ape.
When you’re a developer, the only thing worse and more contemptible than the uninformed code you wrote years ago, is the code that someone else wrote years ago. Not only is it alien to you in makeup and reasoning, this legacy code also features patterns that have gone out of date or even been forgotten.
But lest you, as a manager, assume that this is simply a matter of developers being prima donnas, consider that an encounter with legacy code bother developers precisely because it renders them less effective. They’re professionals, wanting to do good work, and the lead balloon you’ve dropped in their lap is an impediment to that.