Skip to content
loading...

How do you sell refactoring to your team?

derekjhopper profile image Derek Hopper twitter logo github logo ・1 min read  

Refactoring is often a great thing to do. If you maintain a piece of software for years, chances are you'll refactor somewhat regularly.

Even though refactoring is a good practice, your team might have plenty of valid reasons why it doesn't want to refactor something. How do you sell them on the idea?

twitter logo DISCUSS (5)
Discussion
markdown guide
 

"Hey team, we get to use the shiny new thing, and it'll make everything faster! Lets go go go"

// Never mentions the week-long integration struggle


Theres one mantra to follow.

If it ain't broke, don't fix it.

You have to think of a good enough reason to prove the product is "broken", and could be improved through refactoring.

  • The code style is so poor it costs more time editing - let's refactor and lint this
  • This old service is using outdated dependencies that are either dangerous or slower than modern solutions
  • This part of the website needs to be completely re-written in X because it'll help moving forward with Y

As a tech lead it can often be your job to weigh the need to refactor against these other factors (developer happiness, productivity, company budget, etc). You have to decide if you want to focus on cutting costs (like time spent coding) -- or you'd rather invest a loss of a profit for long term payoffs in the next quarter.

If you're not the tech lead, it helps to understand the complexity of that decision making process, and the scope at which you have to pose the problem to garner the right kind of attention.

Want to propose a refactoring from a non-leadership position?

1, Consider when you time it (is it during a sprint or downtime?)

  1. Make sure to actually solve a problem (why get paid to move pixels needlessly?).
  2. Be confident in your decision, and be able to possible prove it with small scale experiments. Seeing is believing.
 

I like your whole explanation here, but I specifically like that you mentioned experiments. You may even be able to do the experiment without mentioning it to anyone (depending). Once you have the results, you can present it - which may end up being an easier sell because you have the results. Like you said, seeing is believing.

 

I start with myself. I refactor and clean code I own and take responsibility and initiative. But if a project smells bad and I know I’ll need more sprint time to tidy up, I present a value versus risk plan to my tech lead. We decide if it’s doable now, and if not we put a ticket in the backlog to pull in the next time that project gets touched. When we plan sprints it’s always driven by business need, but a little extra time can be allotted to pull in these refactoring tickets.

As for selling refactoring to the team, if your culture promotes direct ownership of the code by everyone, then your colleagues will want to refactor to clean code to lower their time spent on bugs. +1 for testing here too.

 

Putting things in terms of moving faster if we have good refactoring practice is always useful but doesn’t always land.

What I’ve found to be helpful are things like CodeClimate which give some tangible “scores” you can reference. It doesn’t tell the whole story, but if you can tell people the code has a big fat F grade, I think it goes a long way.

 

Agreed. Code Climate has been a tool we've used in the past. Like you mentioned, it doesn't tell the whole story, but it's a good tool to have in your arsenal. It puts a grade to something subjective.

Just to think about the other side, do you think there are cases where relying on something like Code Climate could be detrimental?

Classic DEV Post from Jul 30 '19

PublishTo.Dev: Scheduling article publishing on dev.to

Derek Hopper profile image
Golfer, gamer, full stack web developer. CTO @ Ideal Project Group, building @tulasoftware.