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?
Top comments (5)
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?
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.
"Hey team, we get to use the shiny new thing, and it'll make everything faster! Lets go go go"
Theres one mantra to follow.
You have to think of a good enough reason to prove the product is "broken", and could be improved through refactoring.
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?)
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.