I find myself in an odd situation.
I'm doing maintenance programming.
And I'm enjoying it.
Maintenance programming sucks. It's the crazy art of taking someone else's code, guessing what it does, closing your eyes, gritting your teeth and changing something that inevitably breaks as soon as you get it live. It's a dangerous place, fraught with peril. It's depressing and demotivating and dull. Everyone has to do it at some point, and everyone hates it.
But I've made a discovery. Maintenance programming doesn't suck; it's not the work itself that's so bad, it's how you do it. Or rather, it's how it makes you feel.
Look at that description of maintenance programming again. OK, it's somewhat exaggerated and has a tongue planted firmly in it's cheek, but it still holds true. Developers do hate it, and get demotivated and depressed and demoralised. And here's the key - look at all that negative emotion! Things tend to go wrong when you do maintenance programming. And you're looking at other people's code and you don't like how it's structured, and you don't understand it, and it's all just so much stress and fear and general bad vibes.
This emotional impact shouldn't be under-estimated. This stress and fear is directly contributing to the depressed and demoralised feeling. And it's dull because you can't change the structure to something nicer because you're too frightened of breaking things! Who really wants to work in these conditions?
That's right. Maintenance programming is rubbish because of the emotional impact it has on you.
The good news is that this can all be fixed, and very easily. All it needs is some proper unit tests. And doing things test driven is even better.
I've had the luxury of spending the last couple of years working almost exclusively in .net, and there I've been really rather strict about unit testing, and test driven development (not an easy skill to learn, but once things have clicked, there's no going back). But that was all new code. Or so I thought at the time. Looking back it's fairly obvious that I was doing a lot of maintenance programming then, too. I haven't been writing brand spanking new code every single day for the past couple of years! I was changing things and tweaking things and fixing things, just like maintenance programming. But it didn't feel like it. There was no fear, no stress, no depression, no demotivation. And that's because I had a huge safety net of unit tests. Since the tests had been there before the code was even written, this was just taken for granted, and changes were cheap and safe.
But what if the tests aren't there already? This is where Michael Feathers becomes your new best friend. Go get his book Working Effectively with Legacy Code. It deals entirely with this situation, and has guidance and advice for what to do in this situation. It defines legacy code as code without tests. And the basic rule of the book is that you don't touch a single line of existing code until you've got it covered in tests. The hard part is inserting tests where they weren't designed to go, and that's where a large amount of the book comes in handy.
My current project came with some "prototype" code - a single 5000 line C file written by someone else. I had to get this production ready. Are you feeling the fear yet? Me too.
There was only one thing for it. Unit testing in C++. I'm now using Eclipse with a rather nice CxxTest plugin. I've got the full red-green-refactor cycle going, loads of unit tests, and it's all working really rather well.
And the most surprising thing was how it all made me feel.
I'm actually enjoying maintenance programming. I'm not worried about breaking something, because I've got confidence in my tests. I'm not worried about lack of knowledge, because I just write a test that demonstrates how it works. And, even more positively, it's incredibly satisfying to keep the red/green bar green, and to watch the number of unit tests increase, knowing that the quality and maintainability of the project is increasing with every new test. Instead of being limited by negativity, I've got all the fun of deciding how to best improve the structure of the code.
Who would have thought coding could be quite this emotional?
Subscribe