Legacy Code is scary, and you are doing it right now!

Chucky & Tiffany, Haunted House, The Exorcist, Legacy Code.

These all pairs of words represent our worst nightmare.

Imagine, you are at your desk, working on some project you like. Suddenly, your team leader enters the room and asks you to check if you can fix a small issue in one of your team’s app.

You agree and start checking the app. You start by trying to reproduce the bug. So far, so good.

Then you download the repository to your computer and realize the real problem. No documentation, no auto-tests, and a lot of “patches”. You try to compile it and see 199 errors and 2450 warnings.

We’ve all been there (if you haven’t, get off my blog) – legacy code. It’s all around us, it’s inevitable. Sometimes you don’t understand at the beginning but when it hits you, it hits you bad.

These are some hints that will tell you if you are dealing with legacy code:

• You are not sure which branch is the production branch because all the commits look like this “aaaaaaaaaaaa another bug fixed” or “dsadsa” or “changed a to b”.
• There are no automatic tests you can run.
• There is no Development, Integration or Test environment you can use to efficiently test the fix.
• There are 2+ people who laugh at you when they hear about the task you’ve received.

You can notice I didn’t write anything about the age of the software because that doesn’t have anything to do with it. Actually, you might be writing legacy code right now (suspense-music)

Take a moment to think about your projects. Do any of the points mentioned before fit your project? If so, I recommend you to stop what you are doing and reconsider fixing it right now! (OK, finish this blog post and then…).

A good way to avoid writing code that no one will be able to maintain is to have a DoD.

DoD – Definition of Done

Have a written document, written, reviewed and approved by everyone in your team specifying what it means when you say you claim you are DONE with this task.

It can include obvious stuff like “the code is written and it compiles” or “documentation is ready” and it can include more advanced stuff like “DBA has a plan to upgrade” and “Automatic tests ready”. If the DoD is well written, it will help your team to write better software that will be maintained over time.

Moreover, the DoD is a good roadmap to show the PM how much that feature he wants will cost. If until now the PM would ask for a feature and would think that it’s just adding an “If”, you can show him that in order to add that feature, you will need to to all that is written in the DoD.

You can search “DoD examples” to receive ideas of how a DoD needs to look like and, I recommend, after seeing some examples, to have a team meeting and decide on your own what is your Definition of Done.

In my team, we sat one day and though to ourselves how do we see our next projects. How do we want to develop them? What are the requirements we set to ourselves about them? Given these questions, we started writing a checklist that needs to be fulfilled before the software goes into Testing and Production.

Sadly but understandably, we don’t always check all of the items in the DoD. But the idea of having that list has improved our quality of software.

But it’s something really small!

Yes, the best legacy codes I’ve seen (and written myself..) started with that same phrase. Why to go through all the trouble of the DoD if it’s something really small? It really is a small “if”!

I can think about two reasons on top of my head:

First, it is never a small change. That small change will evolve and evolve like a snowball and suddenly, you changed 3 lines, and then 10 lines and then a whole class was changed… You get the point.

Secondly, how can you be sure that small “if” didn’t changed another logic in the code and know you broke the software? The answer is simple – you can’t. There is a saying in my job – What wasn’t tested, won’t work in production. And until now, it was proven right 100% of the times.

To conclude

Do whatever you can to avoid writing code that no one will be able to maintain and will be afraid to touch it. Remember, the next person who will need to work on on that code – might be you.