
Ask HN: How have you dealt with a team that is afraid of refactoring? - ThorinJacobs
When in a position where your company culture embraces code quality, TDD, and other best practices, but some team members seem afraid to refactor in case of breakages, how have you approached shifting the team towards continuous improvement?<p>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&#x27;m not sure if it will succeed.
======
psyc
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 :)

~~~
potta_coffee
I'm pretty much working alone too and I refactor often! There are pros and
cons to working alone to be sure.

------
relaunched
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!

~~~
UK-Al05
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.

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

~~~
ThorinJacobs
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.

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

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

------
tonyedgecombe
_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.

