OK so you are new to the job, just started getting your hands dirty into your first few stories, and things get a little messy. The codebase you’re working in is a complete mess. You don’t just stand there and let it be, hope you’ll be moved onto something post 2010 soon. No, you want to do something about it! As you may already be aware, working in a legacy, or sometimes not so legacy, codebase is not always ideal. Having to deal with large controllers, severe technical debt or general bugs that take ages to diagnose, is a nightmare. In a world focused on fast iterative improvement and mostly no dedicated resource for cleaning up the mess left behind over the years, it seems impossible to even start a conversation suggesting refactoring the projects.

While some businesses are able to dedicate resource towards building a new app altogether, using the latest front and back-end technologies, that is not always the case. Arguably, that does not occur very often. And so, the only thing left is to refactor the system at hand. But how do we do that?

Technically it is possible, for the vast majority of times, but the real problem is: who’s gonna sign that off? What product owner will allow a 6-12 months period of refactoring sprints, by deallocating expensive resource from building ‘version 2.0’ of the product? After all, clients continuously ask for enhancements, and the backlog isn’t getting any smaller, quite the opposite. It seems impossible, but in this post, I put together 3 ways, plus a bonus, you could sell refactoring work without disturbing the waters, or sounding like a prick while you’re at it:

1. Include Refactoring Into The Feature/Story Estimates

The best and most guaranteed way to sell refactoring is to not sell it. I know it sounds counterintuitive, but when it comes down to it, no one wants to hear about it. And that is because the majority of people, be they project managers/owners or sometimes developers, don’t foresee the implications of antipatterns.

Therefore, the easiest thing to do is to include it in the estimate of your feature request. Consider it as unavoidable. Remember, you are the engineer, you decide what’s beneficial for the system in the long run (if you are not trusted for that, that is a different problem).

Say for example you and your team, are given to estimate a new reporting dashboard section, a pie chart representing the number of bookings per gender (hair saloon booking system for the sake of this example). Now, realistically you could just create your own little section, hook up your client with yet another API controller method, and off you go. However, you and I know this isn’t how we’re supposed to do things. You know the controller is a nightmare (be it 600 lines of 6k, the sky’s the limit). And instead of thinking only about the new code to be added, think about what needs to be changed also. This way, instead of a 5h estimation, you end up with a 7.5h one (same with story points).

You are mostly estimating/pointing based on 2 factors: risk and complexity. The reason refactoring needs to happen in the first place is to reduce complexity down the line. This, on the other hand, imposes a risk. That’s one reasoning I recommend.

2. Bundle It Up With Unit Testing

To begin with, don’t get me wrong, some solutions don’t necessarily have unit tests in the first place, due to their size or low integration impact they have in the business. But you’ve got to be open-minded in those sorts of scenarios. Compromises are made all the time. They should be the exception to the rule. If this is the case, then this point won’t be of any use I’m afraid.

However, if the app has the slightest sight of UT, grab it like it’s your last chance. Your 2 – 2.5 h extra effort could result in 50% UT and 50% refactoring. That’s still 1 – 1.25h of refactoring per new feature coming in. Better than nothing, if you ask me. This is like heaven for a feature-driven system where no resource is dedicated to technical debt.

Don’t be afraid to explain your reasoning: Yes, sometimes refactoring needs to happen in order for unit tests to exist. And unit tests are an integral part of the development lifecycle. So, use that to make refactoring an essential part of the feature.

3. Refactor Only Up And Coming Features

There are times when the entire application needs to change, and so refactoring takes place as a buy product of that. Most of the times, for better or for worse, apps stay the same. The technology is not improved, heck, there are projects where not one 3-rd party library has been updated since it’s been installed. So, thinking you can sell refactoring the entire application by listing the advantages it’s unrealistic. You will be faced with pushback coming from management, because ‘Everything works just fine, why change it?’.

On one hand, that could be right. Why would you want to change something that is already working as expected. No bugs there, no issues. Changing it will only expose that area. And good luck getting a second OK to a refactoring spring in the future.

On the other hand, if the area is always being reported with bugs/defects and the performance is on the ground, then yes, that’s a good starting point. (more in a future post, about this particular scenario).

But say the system works just fine, but it’s always a pain to add new system enhancements in. You can apply either one of the above points but only for new customer feature requests. Thus, the system naturally becomes incrementally better over time in an inevitable way.

4. Bonus – Make Them An Offer They Can’t Refuse.

Selling the idea and the reasoning behind is at the core of this. Explain how much the system can be improved 6 – 12 months down the line. Everyone can appreciate a project easier to maintain. Easier means, it is cheaper to support. Cheaper could mean more money invested in new features. See where I’m going with this? This is a short one, but effective. It’s all in how you approach things. Don’t ask for the impossible. Imagine you’d invest your salary in this, how much of it would you like to go into the process? A small percentage right? Be understanding of the business. There are reasons for virtually anything, good or bad. Communication is the key, as cheesy as it sounds (Evolution not revolution).

Finally, avoid falling into the trap of thinking that stopping daily sprint work will do the project/business any benefit. This is going to be seen as a stop from doing the work that pays the bills and people are reluctant to that.

To quickly recap, here’s what you need to consider if you ever find yourself in this situation:

1. Include Refactoring Into The Feature/Story Estimates: Don’t just create separate stories or tasks for it, don’t start a whole revolution only for refactoring. Instead, include it in your current estimates.
2. Bundle It Up With Unit Testing: Make it part of the process your team already adheres to. Unit tests could go hand-in-hand with refactoring work.
3. Refactor Only Up And Coming Features: Avoid fixing the world. A good starting point is to fix the codebase with new feature requests.
4. Make Them An Offer They Can’t Refuse: Explain the irreparable repercussions not doing this can have. While walking them through how this can make it easier to build upon over time.

PS: don’t despair. Sometimes it is just impossible to justify these actions, and you have to give up for the time being. Remember, there will be a time you will have the authority and credit to do it more easily, but maybe not at that time.

Take it easy ✌