Me: We need to throw everything away and start writing from scratch in React. We can go full server side rendered and we won’t need any Rails code at all.

Manager: But we already put weeks of work into splitting the code outside of the main codebase, we can ’t just throw everything away!

Me: Sure, why not?! We’ll be rewriting everything much better and much faster than trying to understand and debug legacy code, written in a technology where none of us is very proficient in.

Manager: We need to find a middle ground.

Me: Alright, alright…

It’s that time of the year, there’s some code to refactor, and in this case is a pretty big chunk of code that some of your colleagues carefully crafted a few years ago. Management won’t like it, but it has to be done anyway.

In the case of Podio’s Webforms the situation was a tad more complicated than usual. The original project was simply to split the Webforms outside of Podio, and it evolved into a major refactoring project of which I will spare you the gory details, so juicy I will share them with you in another post.

I have found out, that when it comes to dealing with big refactoring projects, the process can be weirdly similar to Kübler-Ross’ model of grief, which divides the process into 5 stages: denial, anger, bargaining, depression and acceptance.

I took a shot at preparing you for this, exploring how each stage correlates in a funny way to refactoring code for a big project like we had at Podio, and how to come out on the other side in one piece when you embark on a similar journey.

1. Denial

we don’t need it, that code is perfectly fine as it is

The first reaction, especially from people outside of the development circles, it’s usually of denial and rejection of the necessary changes.

It’s working fine.
It has worked until today.
Just fix the bugs and we’ll be fine.
How hard could it be to add that extra feature?

Don’t be fooled — it’s easy to underestimate how heavy technical debt has become over time when you’re not working daily with the code. This is something non-devs are quick to assume, underestimating the growing effort of “patching it up” over and over again.

What should you do about it

You need to have a very good reason to refactor that piece code. The fact that you don’t completely understand it or, even worse, you don’t own it, is not enough to justify such a great endeavor. If this is the case, best of luck trying to get the go-ahead from your manager.

So instead focus on the specific problems you want to address and how it will help your team perform better. Faster, cleaner, more readable, analyse the greatest challenges you face in working with the current code, discuss them with your team so you’re prepared to represent them from the whole team’s viewpoint, and use them in your proposal.

Define what you want to achieve, and plan accordingly.

2. Anger

we should have been more careful, how did this happen?!

While most tech companies nowadays don’t play The Blame Game™ anymore, the risk is always behind the corner when it comes down to analyse someone else’s code that it’s not as good as we would like to be. Haste, tight deadlines, scope & strategy changes, and human error are only a few of the possible contributors.

It’s important to remember just as there’s no use in crying over spilled milk, no good will come of hunting down the person(s) responsible for the mess.

What should you do about it

Avoid The Blame Game™ at all cost — it’s a waste of resources and harmful to team dynamics. No one will benefit from knowing who made a particular mistake and why. If that person is still around, they’ll learn from the cleanup, so the process does all the dirty work for you. No muss, no fuss!

Use git blame to ask for help, not to point fingers at others.

Focus on solutions, not problems.

3. Bargaining

maybe we can still save it…

You may be tempted to patch up the mess, to avoid refactor and just keep going your way. Let me give an unsolicited, free piece of advice: this is not a solution! This kind of thinking creates the need to refactor. You don’t want to be back in this predicament in 3 months, with an even more dire situation than you have now.

What should you do about it

Don’t give in to the dark side. It may seem like the simplest, cheapest solution but it has zero benefits for the future.

There’s no easy way out. Do your homework!

4. Depression — maybe just melancholy, but…

there’s nothing we can do about the past

Face it: your code is a mess and it’s time to rebuild. Again, avoid the The Blame Game™. Instead, help your team look forward, and get them armed and excited for the challenge that lays ahead.

What should you do about it

Just move on and start the fun — it’s mind over matter

5. Acceptance

let’s do this! And this time we’ll do it the right way

Behind every refactoring project, there’s a great opportunity. The opportunity to get rid of a big chunk of technical debt, to create the setup so you can work the way you want going forward, and to improve your life as a developer. This is huge!

As it happens, with great opportunities comes great responsibility. You are now in charge of making things right, and not creating more technical debt in your wake.

What should you do about it

Here comes the fun part, it’s time to get your hands dirty! Take your time, be patient and attentive, plan carefully and create something great.

If you did all your homework correctly, it will be a while until your piece of code will need some refactor — hopefully

Conclusions

Big refactor projects are challenging and require grand discussions and future-proof decisions. Don’t make assumptions and don’t search for culprits.

Enjoy your project, get rid of some technical debt and write awesome code, that in a few years from now… will be the new technical debt :)

Hey fellow reader, If you liked this story, hit that little ❤ down there and tweet about it, so that other can see it.

While you’re at it, why not follow me on Twitter?
I might have something more to say!