In the world of startups the short deadlines and shifting business requirements seem to result in some pretty gnarly code in your organization’s repository. Eventually, you’ll have the unfortunate task of adding a feature or fixing a bug in this code. If you’re really unfortunate, you’ll either have never worked on said code, or only worked on it a long time ago. Every place I’ve worked at has that code. It’s something that turned out to be a critical, but somewhat static piece of the product. There’s a lot of manifestations of this: it’s written in a different language than the current standard, or it’s using old conventions, or it’s just written by a more naive or rushed programmer (e.g. yourself, a few years previous). When you look at it you just know it’s wrong. Every time someone opens up these files, they sigh quietly to themselves and try to do as little damage as possible and get out of there as quickly and quietly as possible. The fear of making this critical piece of software break overpowers every good programmer’s urges to fix it. Your task, should you chose to accept it, is to stop being afraid and start fixing things.
First, take the opportunity to learn more about the code you’re trying to fix. Maybe it’s got that weird syntax for a reason, or maybe you’re processing some funky legacy data. Ask around for help (or try to remember why you wrote it) and you might suddenly find that it’s not broken at all. Look at old commits to your source control repo (you always write useful check-in messages right?). If the logic behind the weird/bad/ugly code turns out to be missing entirely, you might find that it’s just bad code because everyone is afraid to fix it. That’s the cue to dig in and set things right.
Refactor the existing code by splitting big methods up into smaller ones. Introduce new classes and files to fix broken patterns, but try to leave the existing logic in place where that important business logic is handled. Add comments explaining the code as you see it and more importantly, find our who wrote it (svn blame ftw) and what they intended it to do. Along the way introduce some sane(r) unit tests to actually verify that your code is a drop-in replacement for the existing one. Once you’ve made the world a saner place, you can confidently add that new feature or fix that bug. Best of all, you’ve left it a little better than when you got there. Being a good programmer is often about being a good citizen, and your source code is your community. If you don’t pick up the trash, then who will?
The biggest victory this brings about is that you’ll better understand the intricacies of your product and you’ll have more maintainable and understandable code. This will pay dividends well past the current project or the next few sprints and help improve velocity for anyone touching this code. Most importantly, it tears down imagined barriers that prevent good developers from fixing problems they know about. So don’t be afraid to do the right thing, especially if you have unit tests to back you up 😉