Agile Legacy Code

Primary Menu

RULE 1: All new code is tested code

Picture this, you are working on a brownfield project (hard to picture, right? Is there anything else anymore?). You hate it. It’s a mess, and you would like to clean it, but… There’s always a but. You are afraid, you are afraid to change anything, beacuse the last 10 times you changed something, something else broke.

There are not test to save you, and I’m not talking only about those pretty automated unit tests you read about on the web, I’m talking about anything, even manual tests could help here, and the document with the users requirements? Well that hasn’t been updated in 2 years, so it’s useless. Even if you wanted to test the whole system at every change, there is no way to be sure if it is behaving as expected.

There is one rule you need to know when you work in an environment like this. Is the only rule that can make a dent in this kind of software. It isn’t simple, it isn’t fast. But if you follow this rule, with time you will find yourself working in a more pleasant project.

All new code WILL be tested by automated tests

It’s hard to admit it to yourself, but that mess I was talking about, well… we wrote that mess. To complete a deadline, to appease a client, to get home in time. We didn’t write tests, we didn’t update the documentation, we didn’t refactor once we had “working” code.

Now you will tell me that no, this isn’t your fault, you didn’t write this mess. You just started working on it a week ago, once the main developer changed jobs. Well, but you wrote a mess in your previous job and somebody else is maintaining it. KARMA!

It doesn’t matter if you wrote this particular instance of mess, what matters is that you are responsible of it, you are maintaining it, and you will be doing it for the foreseeable future. Now might be acceptable to say “This is a mess, the previous developer was a noob and made a big pile of mud, instead of a software”, but in 6 months, 1 year or 2 years, when you will still be working on it, there’s no way you can say that. And if you do your colleagues should ask you “And… what have you done to improve it?”.

“Nothing” is not an answer.

You had time.

Time is all you need, and time is what you have. Start small. Every little change to the software is new software, it is your little greenfield project. Treat it like that. Work on a new class, write tests for that class, refactor that new beautiful (little) class, and then go back to the mudball and make a one line change calling your new wonderful perfect class.

OK, at first it probably won’t be the most beautiful piece of software ever written, but, it will be tested, you will be able to refactor it, you will be able to improve it, and keep working on it. You won’t be afraid of it, and nobody should.

The beauty of this is that little by little you will carve your way out of the mudball. More and more parts of it will be sane, will be tested. And with proper refactoring techniques you will be able to isolate and test also some of that horrible code. And once it is covered, you can refactor it.

I’m sorry for you. I’m sorry that I can’t sell you the magic silver bullet that will fix all your problems in a week (in that case I could be rich), but this is the way, this is the only way to improve broken software, start small, keep going and sooner or later (OK later), you will be working on good software again.

Just keep in mind:

All new code WILL be tested by automated tests

Author: Maurizio Pozzobon

Maurizio has 5+ years developing solutions in the insurance industry. He is passionate about doing the right thing right, so he works in a tight loop with his clients to deliver the best solution possible.