Development

Surviving a legacy code project

Oftentimes when I do consulting I am called in to fix someone else’s mess.  Some refer to legacy code meaning code that’s  deprecated, or code in an “old” technology stack.  Some refer to legacy code as code that lacks unit tests.  Most likely you’re going to get both… at once… and at first you’ll feel like this…

 

However, after the grieving process you can do one of two things.

  1. Quit your job/contract/project.
  2. March forward in maniacal madness.

Now I’m being facetious when I compare work on a legacy software project to personal grief, but it’s undeniable that it can affect your perceived your value.  My personality drives me to make applications work- to become better.  Yet we are sometimes put in situations where we don’t have the tools, budget, or environment to make something better.  Here is how I describe the process.

Legacy Software Grief (2)

While I can’t offer you anything more than my personal experience.  Here are some things that have helped.

Arrange a “bitch session”.

Get together with a set of programmers (co-workers/peers) and discuss exactly what makes the application or solution so horrible.  Use graphic metaphors- really try and lay into the system.  Burn off some of that anger.  In reality you should try and do this enough to keep you sane, and if you make it entertaining enough your friends will sympathize.

Set a deadline

For the truly hopeless projects you have to take into account your sanity and reputation.  Is the code base ever going to get better?  Can you control any of the outcomes?  If the answer is no start thinking about an exit strategy.  Try and remember if you aren’t learning anything except patience, you’re in a bad spot.  Figure out the minimum acceptable time to support the project without being labeled a quitter.  When you do leave the project you’ll hopefully be given the opportunity to give your opinion and document it.  “Going forward I think it would be a good idea to re-write the data layer.” or “In the future, we need to incorporate this external service into the application, if possible”.

If you get pigeon-holed

Life is too short.  After putting in a requisite time (3 – 6 months, maybe a year)- stabilizing the project if possible, leave.  If your employer wasn’t smart enough to listen to you, you’re better off.

Leave a Reply

Your email address will not be published. Required fields are marked *