How to handle pressure to deliver, when maintaining legacy code?

Question

Here's a question that has been bugging me. I'd like to think that I prefer writing elegant C++ code. — You know, well designed, clean, documented code. But, what do you do if you are under pressure to deliver and maintain large legacy code which is supposed to meet functional and, especially, performance requirements?

After a while, my code just looks like everyone else's who were in charge of the processes before me. While I curse the people who used hundreds of global variables, eventually I end up adding to it. Does this sound familiar, or should I just forget about it?

Edit

It's also about improving myself because I don't want to keep on writing code the way I do, I want to learn and put those ideas into practice. But, maintenance, deadlines and existing library implementations in use at work mean that I have to keep on doing the same sort of thing.

Edit

Actually, these days I am developing a plugin system which is not that heavily constrained. So I can ask around and get ideas and design and develop. Which is how it should be I think. And so I joined SO. :D

Edit

I think, the real question is, assuming that the layers above you are frozen (deadlines, project decisions, etc.), what can you do not to drown assuming that you are an average programmer who wants to get better?

Answer 1

Try your best given the requirements. No code is perfect.

Answer 2

Sometimes it's possible to wrap legacy code behind shiny new, nice interfaces. Then you can try to create your new features against these interfaces. However, modifying legacy code doesn't get easier this way.

Another approach is non-technical: convince your manager that good code will result in more $$$ after some time.

Answer 3

My personal experience is that elegant code is much faster to write. Because you just write a lot less code then you would when writing non-elegant code.

Answer 4

Well, if you have to deliver (almost) immediately, you might finding yourself just hacking around to get your program to work correctly.

I personally find myself adding lots of TODO comments in those situations. However, I configured my editor to highlight such comments so I know instantly that I have to do something about those, if I come across them. So, if I got time after delivering, I implement my TODO things so I remove them one after another.

The thing that annoys me most when I am under pressure is if I don't comment anything anymore. My advice is not to drastically reduce commenting if you're under pressure, because otherwise you might sit looking at your code thinking "WTF?!".

Also, there are many tools out there that help you refactor your code. So if you encounter some smelly code, just think about how to refactor it and do it.

As wok mentioned, no code is perfect. Try to code as good as possible, and keep in mind that there's something to do you should fine-tune later.

Answer 5

My experience is that it is possible to refactor code a little at a time: add a comment here, rename a variable there, fix some loop here, set some function to const there... So step by step, your messy, buggy, laggy code becomes -- well, not elegant -- say: manageable.

EDIT:
Oh, and request that management gets you a Visual Assist license. That plugin really helps with quick-and-easy refactoring.

Answer 6

I code slower, and better. I check my code twice, and look for more hidden bugs. I prepare for the next "we need to deliver yesterday" deadline.

Let the management deal with timing, I deal with code. Time is of no relevance to me.

Answer 7

My advise is that dont get panicked, everything takes time. With more practice and time I bet writing elegant code will become your instinct.

Answer 8

1. remember, this is just work. If your client/lead/manager is not keen on upgrading, don't bother.
2. remember, you are not the one who is going to maintain this forever, it will eventually be transitioned to someone else. Ideally, you would want it to be nice for the next guy, but if your code looks different from someone else then you're going to give more problems for the next developer who's idea of code reuse is copy and paste
3. remember, you're not paid to do a regression test of the code, regression tests are very expensive.

However, there are things you can do.

1. Put in place a unit test framework (preferably something you didn't write such as NUnit, JUnit, unitpp, Perl::Test, etc). And start writing test cases to prove your code will always work as you would expect. You would have the freedom to write the code anyway you want.
2. Simplify the build/test process by creating or updating the make files that compile AND test your code.
3. Version Control yourself. Just because you have a centralized version control system, if it is not sane enough for you i.e. checkin/checkout style, CVS, very slow to do anything, then install Bzr or Git on your local machine and version control. At the very least you can track your changes.
4. TODO as someone suggested earlier, I use that to put in notes when I disagree with how things are implemented.
5. Along with the TODO add documentation to your code that could be used by generators such as Javadoc or Doxygen.

By doing the above, you can slowly bring about changes with your peers without impacting the "slower" folk (even if it is your lead/client/manager). Since it just improves your work, shows leadership among your peers, makes things more fun for everyone except the slow folk who would likely think you're after their jobs.

Answer 9

What I usually do is tell my manager to keep in mind that I may be able to finish this in time (or as fast as I can) but I will have to take time afterwards to clean the code and refactor it, or otherwise the time needed for maintenance and developing subsequent functionality grows exponentially.

If pressed for explanations, I tell them that when pressed for time the only thing that can be developed is duct-taped to hell. It probably will work in a pinch, but you don't want it in your production code.

Good design takes time. So does good development. Once a manager understands that, the choice to rush me through the code is theirs. So is failure to meet deadlines because there was no time for refactoring.

When you are not pressed for time, make the time to refactor, one piece of code at a time. Don't make a fuss about it, just squeeze it in there. Your fellow developers will thank you, and the codebase will slowly get better. This may not be possible if you have draconian managers, or if you need to explain each check-in you make to a pointy-haired boss.

Answer 10

We, programmers, notoriously hate maintaining code for fear of living this hellish situation. Yes it is a very common situation, and yes, most people usually react by piling more hack over the mud.

From my experience, if you are thrown in bad code, with a tight deadline, there is not much more you can do than continue spreading the disease at some level. If the employer is not willing to give you the time to fix the old stuff, there is no miracle solution.

However, there are ways to mitigate the problem :

• Refactor the fast and easy things. Sometimes small changes go a long way toward helping you and your coworkers understand the system. Put all those globals in structure or a singleton if you can. It's not much, but it's still a small step forward.

• Extract method is your best friend. It's simple and efficient.

• When possible, write clean code with clean interfaces that interact with the crap code. Don't let the bad code infect your code. Sometimes, just puting your own code in functions helps a lot.

• Advance in small steps. Don't try to rebuild or refactor the whole thing at once. You will risk failing and give up entirely. You are better making small changes than not making any because you gave up.

• Do not panic! Understanding unknown code is always hard at the beggining, but the reality is, you will (unfortunately?) eventually understand the madness at some point.

Answer 11

Find the strength to say no.

You might be surprised at the results (of course, it helps if you are marketable, in case you aren't surprised at the results).