loading...

re: How do you sell refactoring to your team? VIEW POST

FULL DISCUSSION
 

"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.

code of conduct - report abuse