Often times, the manager is trying to be risk-adverse by not allowing a troublesome piece of code to be changed. But in pushing off the refactoring / beautification - the risk is just being pushed off, not adverted.

But what this is crying for is better unit testing on this piece of code. If you have a robust set of unit tests for a piece of code, managers are much more likely to allow the code to be refactored because your unit tests will help define if the code changes that were made did not break any of the functionality of the code.

Therefore, when dealing with a manager who is concerned about changing the code - think about it from their perspective. They are worried about destabalizing the source code base not just the time investment involved. Combat this with a well-defined unit testing framework and test suite, and I think your arguments to refactor / beautify will be met with much less resistance.

Continuous Integration is a great way to show and track the evolution of the code base.

I don’t know how this helps the conversation. I hope it’s not just a case of “you can’t know what it’s like to work with good/bad code unless you have done it yourself.” In that case, it is just a trust thing, like a car mechanic. If you trust your mechanic, and he recommends replacing some belt or something even though the car’s working okay now, you’ll let him do it; if not, you’ll figure he’s gouging you, and not do it (and then your car will fail spectacularly in a month). Unfortunately, code is maybe even harder to measure than cars.

In short, I agree!

You hit the nail on the head. So the answer has to start with “depends” …

One strategy is to find an incremental approach. Manager have an easier time if you can present a case like, “I have several small steps in mind, about 4-8 hours each, that will improve this troublesome code. At the end of each step, the code will be fully working and a little better then when I started”. The point here is to give control of the process to the manager so they can decide if time/budget is available and make a trade off decision.

Another strategy is to attack as you work through bug reports. Each time a bug is investigated, make a deal with the manager that you will make improvements via tests and coding improvements in the specific area of the bug. Like the preceding strategy, the manager is still in control and you are only adding a small incremental effort (since the bug had to be fixed anyway). The increment needs to have value in preventing reoccurrence of the present bug and of future bugs that have similar location or characteristics. The changes/tests will also strengthen the code so that future developers will have fewer problems understanding, extending, and maintaining.

For a real mess, you may have to do some initial work before you can even present a cogent case to the manager:

If you can wrap the smelly class in some tests that verify current functionality, you may be able to incrementally improve it. Structure tests for two purposes: to identify current functionality that your incremental change inadvertently breaks; and to test the incremental change. This will be imperfect, but much safer than without the tests. Also, each incremental improvement adds more tests, so risk is lowered with each step.

You might also try mechanical refactorings like breaking methods into smaller methods, extracting “helper” or “utility” classes. These are quick and relatively low risk and at least reduce the problem. Once you work through some of these refactorings, the intent of the code will become more clear and you can begin to make more targeted refactorings.

Or you may try running a static code analyser like PMD or Eclipse Metrics. Explain to your manager what Cyclical complexity means and try to get approval for incremental improvements that specifically improves the metrics. This may appeal to the manager because it provides feedback of your refactoring activities.

–jH

Say, for example, you (the developer) have a large cumbersome class (with no unit tests) that keeps being the source of little bugs. You want to beatify it, refactor, add tests, make it readable — but this will take time and result in a functional match if all goes well (only hopefully without the defects).

The manager sees a large time investment, the possibility of adding new bugs, and really doesn’t see the problem with the mostly functional class that you have to dig into every few months, figure out how it works all over again, and put band-aids on. Is there a good answer here?