Return to site

CODING TEAM THEORY: Expanding Refactor

ยท coding,team

triggers a dramatic widening of scope.

What was intended as an optimization exercise, becomes a wholesale rewrite.

๐‡๐จ๐ฐ ๐ญ๐จ ๐ซ๐ž๐œ๐จ๐ ๐ง๐ข๐ณ๐ž ๐ข๐ญ

A small amount of legacy refactoring is healthy.

Itโ€™s when you notice a whole slew of changes in areas that are unrelated to the feature at hand.

Look at the Work Log for outsized code commits in sets of files that seem completely unrelated to the feature at hand.

Talk to the engineer, expanding refactors are rarely driven by the product teams.

๐–๐ก๐š๐ญ ๐ญ๐จ ๐๐จ

Open the topic up for discussion with the team.

Ask team members to make a case for and against the refactor,

and then come to a conclusion about whether itโ€™s best to move forward with the project,

drop it, or tackle it with a different approach.

It can also be useful to provide standards around what success is โ€” what โ€œdoneโ€ looks like.

That way, everyoneโ€™s clear around what the project is and isnโ€™t,

and so the expanding refactor doesnโ€™t consume too much of your teamโ€™s time and energy