Maintaining code that is close to software rot

Question

Let's say you're the lucky programmer who inherited a code that is close to software rot. Software rot as defined in Pragmatic Programmer is code that is too ugly (in this case, unrefactored code) it is compared to a broken window that no one wants to fix it and in turn can damage a house and can cause criminals to thrive in that city.

But it is the same code that Joel Spolsky in JoelOnSoftware values in such a way that it contains valuable patches which have been debugged throughout its lifetime (which can look unstructured and ugly).

How would you maintain this?

Answer 1

Have a look at Working Effectively with Legacy Code by Michael Feathers. Lots of good advice there.

Answer 2

You can do a few things:

• Refactor the code to make it more maintainable. If the code is being used for feature development as well then refactoring will make sense.
• If the code is legacy code and is touched only for bug fixes then I would suggest you only fix as much as required and when required.
• Often, the first impression people get from such legacy acquired code is that its messy. Give it some time and get comfortable with it. You may see some valid reasons as to why the code looks this way with time to come...

Answer 3

First, make sure that you have a robust test procedure for it, and that it will actually be tested again in depth, by several people (you, QA, ...).

Then, take some time, day after day, to improve the small parts you have to modify. The key is to have a management that understands "why it takes longer as expected". Explain that you have to do refactoring and that it is important for both short and long term, ask other developers to review the existing code and confirm your arguments.

Answer 4

Welc is a great book. You should certainly check it out. If you don't want to wait for the book arrive, I can summarise the bits I think are important

1. You need to understand your system. Do some throwaway coding to understand the part you need to work on. E.g. be prepared to try and do some work to get the system under test based upon the knowledge that you will probably break it. (understand what went wrong)
2. Look for areas where you can break dependencies. Michael Feathers calls these seams. They are points where you can take abit of the legacy system and refactor it so it will be testable.
3. As you work on the system add tests as you go.