10 tips for convincing the managers for refactoring

Don’t use word “refactoring,” ever. Don’t talk about rewriting ever. The managers aren’t willing to hear it, so dress the needed work in the words they want to hear. How? What about speaking about improving the stability, throughput of the system or faster delivery? Of course, not every refactoring leads directly to these goals, but what helps you to maintain better or develop your software, then it can lead to them.

This is so much important. This means, you don’t need to convince anyone for doing your job properly. The refactoring is the inextricable part of the software development, so why to ask someone to let you doing your job in the best quality? You, as a developer, are responsible for the quality of the product and if you need to refactor anything, it’s needed to be done regardless of what the managers says. After all, it’s embarrassing to call ourselves a good engineers when the quality is not built into every piece of produced code.

In ideal world it also means, no refactoring tasks in the backlog.

Each manager|product owner, knows the numbers better than anything else. Even the product owners with technical knowledge. So when you are asked why something take so much time, give them exact numbers on which you spent the most time. Even when it would be the thinking the whole day where to put one line of code. Just don’t talk about refactoring or why it’s not technically possible to add this or that feature.

Use the word “interest” often. This is working in the same way as the numbers. Anyone who is familiar with the meaning of the interest, he understands that it’s much easier, in the long run, to not accumulate debts with interests from beginning.

Sometimes is the best to let the managers, who aren’t convincible for anything else than working on the features, learn about such technical needs in a hard way. See what will happen when the production servers crash, and there is any significant outage. And of course, measure the cost of such outages in money and numbers.

Of course, it can lead to the situation without possible return to the reasonable piece of software, so it’s the worst advice on this list.

If there are part of the software which is frequently touched and they aren’t in good shape, focus on them. Time spent in such places will return the investment in the best ratio.

When the managers aren’t willing to hear about refactoring and are directly against including a risk of refactoring to the current production, keep the refactoring separately and added it to the software in the less critical time.

Also, it’s a good strategy to improve software incrementally - one can say that 15 minutes per day is too little, but count it for half a year, and you have 30 hours of working on the quality only.

It’s essential to have a way how to measure the benefit of refactoring. Try to accumulate as much as metrics (I mean static analysis, bugs arrived, time spent on bugs, test coverage, time needed to implement a well defined feature with similar scope, etc.) from the current state and compare them after refactoring are done. Not only managers can retrieve such data from issue tracking tools, but we also have the same metrics at our hands.

When you have the numbers proving that the overall quality is increasing, it’s a big win for you and for your bosses which make your life so much easier.

Sometimes (and it’s related to the advice number 2.) is better to do something even without permission. It means it’s better to follow the industrial standards, quality advices even when the others are not convinced about it.

The software is changing every day, refactoring done yesterday and not included into software at the same time denote additional time needed today. Being able to operate on such moving parts is essential for refactoring.

Such things as keeping the refactoring as smallest as possible, including the refactoring in bug fix or feature implementation, significantly help with regular increasing of the quality.

Well, this is my favorite one. When someone is worried about making changes, then he lacks confidence in his abilities. You have the luxury of a comprehensive set of advice, knowledge laying around and experience gathered by other, that it’s simple with starting with small changes and continuously improving own abilities to making bigger and bigger changes.

By making changes you are always learning, even when you are wrong with your changes, it means that you aren’t pussyfooting and you are moving to be better as well as your software.