How do you stay productive when dealing with extremely badly written code?

Question

I don't have much experience in working in software industry, being self-taught and having participated in open source before deciding to take a job. Now that I work for money, I also have to deal with some unpleasant stuff, which is normal of course.

Recently I was assigned to add logging to a large SharePoint project which is written by some programmer who obviously was learning to code on the job. After 2 years of collaboration, the client switched to our company, but the damage was done, and now somehow I need to maintain this code.

Not that the code was too hard to read. Despite problems—each project has one class with several copy-pasted methods, enormous if nestings, Systems Hungarian, undisposed connections—it's still readable.

However, I found myself absolutely unproductive despite working on something as simple as adding logging. Basically, I just need to go through the code step by step and add some trace calls. However, the idiocy of the code is so annoying that I get tired within 10 minutes of starting. In the beginning, I used to add using constructs, reduce nesting by reversing if's, rename the variables to readable names—but the project is large, and eventually I gave up. I know this is not the task I should be doing, but at least reducing the mess gave me some kind of psychological reward so I could keep going. Now the trick stopped working, and I still have 60% of my work to do.

I started having headaches after work, and I no longer get the feeling of satisfaction I used to get—which would usually allow me to code for 10 hours straight and still feel fresh.

This is not just one big rant, for I really do have an actual question:

Is there a way to stay productive and not to fight the windmills?

Is there some kind of psychological trick to stay focused on the task, instead of thinking “How stupid is that?” each time I see another clever trick by the previous programmer? The problem with adding logging is that I actually have to understand what the code does, and doing so hurts my brain in an unpleasant fashion.

Answer 1

I'm sorry to tell you, but not all jobs are full of sunshine and glamor. The majority of development tasks involve drudge work like this. Sad, but true.

You are tasked with an important job, even if it's boring to the point of watching paint dry. It's important for two reasons: 1. It add much needed logging to a large system so that when something goes wrong you'll have a tool to help you find it. and 2. It gets you familiar with the code base so that if and when something goes wrong you can jump in and fix it.

You are basically creating your own safety net here. Glamors, no, but important yes!

So, that being said how should you motivate yourself? When I have a mind numbing task at work, I set goals for myself. Finish doing task x by the end of the week. If I make my goal, I reward myself. New restaurant I want to try? Go Friday night if I finish. New movie just came out? See it on the weekend if I finish.

I find talking with my supervisor and letting him/her know where I'm at and how I'm progressing keeps me accountable. If I tell them I'll be done by Friday, I feel more inclined to get it done by Friday b/c I told them I would have it done.

Keep faith that once you complete this task and you've done it well, on time and on budget that people will notice and when that shinny new project comes along, your name might just be suggested as the one who gets it. :)

Answer 2

Keep a file of candidate code snippets for submission to thedailywtf.com. Even if you don't really intend to submit them, it gives you a bright side to finding some code that's even worse than average.

Answer 3

I was in a similar situation, tasked with cleaning up a large body of poorly written, massively copied-and-pasted code.

To maintain my motivation and my sanity, I wrote a script called current_score that counted the LOC in the project (which steadily decreased, as I eliminated duplication and switched to better algorithms) and compared it against the LOC when I started. Whenever I got discouraged or frustrated with the mountain of code I was facing, running current_score would give me a sense of tangible progress and would remind me of how much I'd already accomplished. And it was fun to see just how high of a score I could rack up when tackling a particularly bad section of code.

I'd look for similar metrics that you could easily script to give yourself a sense of progress and to turn it into a game of sorts. Lines of code (just run wc -l), cyclomatic complexity (which should go down as you clean up those nasty nested "ifs"), lines of code which have been touched by you instead of your predecessor (I think that FishEye can tell you this for $10), etc. You could even write a Perl script without much trouble to count the number of code blocks that don't yet have logging statements.

Answer 4

I've seen this book recommended: Working Effectively With Legacy Code, but luckily haven't had a need to read it.

Like you are doing, refactor what you need to so that you can understand the code and just remember that you are resuscitating a system, which will pay off when you're maintaining it.
That should hopefully put a spring in your step on the way home.

Answer 5

Try to break the project up into chunks. Each day learn how a specific chunk works. Trying to understand it all at once is probably what is stressing you out.

Take pride in making the project better. Are there other coders you can talk to? It helps to stand around the water cooler discussing/laughing at the latest logic you found. I try to do this to keep a jovial atmosphere at work.

Answer 6

Take extensive notes to organize your questions, thoughts, and understanding of the system. This has worked wonders for me when dealing with large legacy systems. It helps crystalize your understanding, helps put the open questions into words, and because your thoughts are already put together it makes it easier to communicate spontaneously with others about problems/questions/ideas/etc.

As an example, as I'm going through a piece of the code, I'll be taking notes to myself constantly. This is my conversation with myself. The mere act of writing helps more thoughts come out and helps me understand things better. After a while I may have a Eureka and need to draw out a little diagram with the "bigger picture" on paper to illustrate what I just thought of or what pieces I just put together. I always do this on paper only, getting rid of all the distractions of the computer. This lets me be more methodical and thoughtful about what I'm doing.

This is basically a convenient way to have a perpetual conversation with a domain expert :)

Answer 7

I know you may feel unproductive because you're looking at it from the perspective of 'I'm only adding logging' when in fact, you're adding logging and doing a lot of refactoring. Your supervisor is probably aware of the code situation. Everyone may not appreciate it now, but when you get a request to add a really interesting and challenging feature, you'll be glad you cleaned up the code.

Answer 8

Gamify your work. For example, give yourself 5 points each time you ask a good question about the code, and 10 points each time you answer it. Give yourself a badge each time you refactor a method or add a new feature. Once you accrue enough points you get privileges like coffee breaks or biscuits. Once you complete the whole project you get the privilege to treat yourself to something you really want.

Answer 9

In these Cases I tend to rewrite a section of code. To make one area suck less and then I just add logging some where else. Then clean up some more code. Bad code is only bad if you leave it there.

Answer 10

The trick to not getting bored or angry so you stay productive is to accept that the code is poorly designed. Accepting your position to having to understand and update the code will allow you to not keep commenting on "how stupid that is" and instead quietly accept it and move on.

Another trick is having a good homelife to look forward to at the end of the day. Girlfriend, friends, games anything will work, to give you a goal to get through the day and make the trudging though bad code all worth while.

Answer 11

"Working Effectively with Legacy Code" by Michael Feathers may help.

If you're worried about breaking things when you change them, write some tests first, make sure they pass before and after you make your changes. Writing the test should help you to summarise and understand what a given piece of code does and will allow you to edit with confidence.