Ask HN: How have you dealt with a team that is afraid of refactoring?
11 comments
Almost every team I've worked on has explicitly forbid refactoring, as well as any check in not directly in service to an approved feature addition or bug fix. And the bug fixes generally need to be minimal. A long time ago, I believed I might get somewhere by promoting refactoring. That got me nowhere. Then, I believed it would be best to quit and find a team that liked refactoring. But I didn't find any teams like that. Now, I mostly work alone, so I don't have to give a hoot what the rest of you are doing or fretting about anymore :)
I'm pretty much working alone too and I refactor often! There are pros and cons to working alone to be sure.
There are several things you mentioned that I'd encourage you to continue to parse. Breakage, test coverage and code [quality] improvement are three areas you mentioned.
The assumption that refactor leads to breakage doesn't have to be true. It might be, if you are coding in a live environment, if you aren't feature / issue branching, if you aren't breaking up coding work into modular pieces, or any other number of scenarios. If that's the case, the benefits of a modern workflow should be discussed and a new process introduced. Baby steps.
Thorough tests may be a side of a high quality code base. But, the value of them is about reducing bugs / errors. Start with that and lead by example. Once again, have a discussion about the value of adding something.
Same with code quality...however you define it.
Now, since you are new, it seems like you've worked other places that were engineering enlightened and you want to show everyone a better way. Be careful so that your enthusiasm / experience doesn't come across as you being an know-it-all, condescending, superior, etc. First, lead by example. Second, share, preferably when asked. Lastly, teach.
If you weren't hired to modernize practices, and even if you were, you have to become a part of the team first, before you can change it. People have to know you're invested in them before they'll invest in you. Which is so say, no one cares about what you have to say, until they know that you care.
Good luck!
The assumption that refactor leads to breakage doesn't have to be true. It might be, if you are coding in a live environment, if you aren't feature / issue branching, if you aren't breaking up coding work into modular pieces, or any other number of scenarios. If that's the case, the benefits of a modern workflow should be discussed and a new process introduced. Baby steps.
Thorough tests may be a side of a high quality code base. But, the value of them is about reducing bugs / errors. Start with that and lead by example. Once again, have a discussion about the value of adding something.
Same with code quality...however you define it.
Now, since you are new, it seems like you've worked other places that were engineering enlightened and you want to show everyone a better way. Be careful so that your enthusiasm / experience doesn't come across as you being an know-it-all, condescending, superior, etc. First, lead by example. Second, share, preferably when asked. Lastly, teach.
If you weren't hired to modernize practices, and even if you were, you have to become a part of the team first, before you can change it. People have to know you're invested in them before they'll invest in you. Which is so say, no one cares about what you have to say, until they know that you care.
Good luck!
Thanks! Yes, so far my previous teams have been very diligent - almost too much - about testing and refactoring, and I'm trying to be very cautious about not offending.
This sounds like very sound advice - slow and steady wins the race I suppose
This sounds like very sound advice - slow and steady wins the race I suppose
The thing is developers as a whole like writing good code.
Code quality is often the result of how much the business values good code. If they don't they will simply want everything done the fasted with no time for refactoring.
That sort of pressure comes from top and is hard for a single dev to change.
Code quality is often the result of how much the business values good code. If they don't they will simply want everything done the fasted with no time for refactoring.
That sort of pressure comes from top and is hard for a single dev to change.
"As I am fairly new on the team"
This is the key point. Yes refactoring is not a bad idea but have you spent enough time with the current codebase to understand why things are done the way they are ? Even if the code is sphagetti, the point is that you may not have all the background yet on things and you need to spend a bit more time understanding everything before you suggest major refactoring. Not to mention that unless it helps with real dollars (more money for the team/company), you may face resistance.
Having said that, don't be afraid to challenge status quo but make sure you have enough background information before making assumptions. It is much easier to come from outside and look at everything being broken (which may very well be but still need to understand it in detail).
This is the key point. Yes refactoring is not a bad idea but have you spent enough time with the current codebase to understand why things are done the way they are ? Even if the code is sphagetti, the point is that you may not have all the background yet on things and you need to spend a bit more time understanding everything before you suggest major refactoring. Not to mention that unless it helps with real dollars (more money for the team/company), you may face resistance.
Having said that, don't be afraid to challenge status quo but make sure you have enough background information before making assumptions. It is much easier to come from outside and look at everything being broken (which may very well be but still need to understand it in detail).
This is really great advice. You're right - it's really easy to make assumptions about the code and it's definitely caught me at least once!
So far I've been trying to keep my changes in service of a specific feature, and keep as light-touch on existing code as possible whole still making improvements. Wrapper classes have helped with this a lot.
So far I've been trying to keep my changes in service of a specific feature, and keep as light-touch on existing code as possible whole still making improvements. Wrapper classes have helped with this a lot.
The fact that a newcomer has difficulty reading the code implies it's bad. Not simply a lack of understanding.
Good code should be easy to pickup even for newcomers.
Now there maybe reasons why it's bad, time constraints, no time for re-evaluating the design. But that doesnt change the fact that it's bad.
Good code should be easy to pickup even for newcomers.
Now there maybe reasons why it's bad, time constraints, no time for re-evaluating the design. But that doesnt change the fact that it's bad.
1. Be a boy scout - leave any code better than you found it.
2. Write functions, components, patterns (etc) that make other people's lives easier.
3. Earn trust over time in small ways like this, and you will be entrusted with bigger architectural refactoring decisions.
The only reason a refactor will ever get approved is if it can demonstrably lead to increased efficiencies in the near future. This is often true (when done well), but you have to be able to demonstrate why, beforehand - which is the hard part.
2. Write functions, components, patterns (etc) that make other people's lives easier.
3. Earn trust over time in small ways like this, and you will be entrusted with bigger architectural refactoring decisions.
The only reason a refactor will ever get approved is if it can demonstrably lead to increased efficiencies in the near future. This is often true (when done well), but you have to be able to demonstrate why, beforehand - which is the hard part.
Refactoring frequently has to compete for resources with new feature requests and bug fixes. Even when team members are sure refactoring will help considerably, it can be hard to get traction.
Performance testing can highlight areas of the code that need help, so work to improve scaling and performance abilities can be used to justify resources to refactor related code.
Sometimes a new feature request can be used similarly where the refactoring and new feature development is a better option than trying to develop only with existing code.
Performance testing can highlight areas of the code that need help, so work to improve scaling and performance abilities can be used to justify resources to refactor related code.
Sometimes a new feature request can be used similarly where the refactoring and new feature development is a better option than trying to develop only with existing code.
As I am fairly new on the team
This is the key point, you almost certainly weren't hired to "fix" other members of the team.
This seems like a very long game to play, however, and I'm not sure if it will succeed.
To some extent it shouldn't matter, if you have a long career in this business you will inevitably come across broken teams and dysfunctional organisations. Knowing you are doing good work keeps you sane in these situations.
This is the key point, you almost certainly weren't hired to "fix" other members of the team.
This seems like a very long game to play, however, and I'm not sure if it will succeed.
To some extent it shouldn't matter, if you have a long career in this business you will inevitably come across broken teams and dysfunctional organisations. Knowing you are doing good work keeps you sane in these situations.
As I am fairly new on the team, my approach has been to add more and better unit tests, and slowly improve the code via small refactors, and let the results show themselves. This seems like a very long game to play, however, and I'm not sure if it will succeed.