Legacy applications are like zombies

Update: this blog is no longer active. For new posts and RSS subscriptions, please go to http://saintgimp.org.

I should have posted this before Halloween when I was first thinking about it, but hey, better late than never.  Here’s what I wrote on Twitter:

There are 76 different VS projects in this crazy thing I've inherited. That's about 50 projects too many. Must consolidate!
5:25 PM Oct 23rd from TweetDeck

When working with large legacy apps, there's only one thing you need to know. Zombies. Legacy code is like zombies.
2:41 PM Oct 27th from TweetDeck

@SaintGimp Rule #2 Double Tap
2:45 PM Oct 27th from Seesmic in reply to SaintGimp

@SaintGimp if legacy code is like zombies, does that make unit testing and refactoring like a chainsaw and shotgun?
3:12 PM Oct 27th from TweetDeck in reply to SaintGimp

At the office on Halloween, locked in mortal combat with my zombified legacy app. Appropriate, I guess. Die, die, die!
10:32 PM Oct 31st from TweetDeck

So far, just in one sub-section, I've hacked it down from 46 projects to 24 projects and from 34K text lines to 14K text lines. Seriously.
10:44 PM Oct 31st from TweetDeck

And it still has the same functionality. Once again, people, source code is a liability, not an asset - more is not better.
10:55 PM Oct 31st from TweetDeck

I would add that the area I was working on went from 6,800 executable lines to 3,200 executable lines.  (Executable lines is so much smaller than text lines because Visual Studio is really conservative about what it considers an executable line.  Interface definitions don’t count at all, for example.)  The smaller number includes all of the unit tests I added for the code I rewrote, so the amount of code I removed is even larger than it appears.

Believe me, these numbers have nothing to do with my skills as a programmer.  Rather, they reflect my, um, target-rich environment.  When a code base is yanked this way and that over several years without much thought given to the overall cohesive direction of the project, a lot of cruft builds up.  A little time (ok, a lot of time) spent thinking about what the code is actually supposed to accomplish clarifies a lot of things.

Comments (0)

Skip to main content