How is refactoring discussed at your organization?

#discuss #career

However you want to take this conversation, I'd love to hear what it's like in your situation.

Top comments (5)

If you mean larger refactors, then it is discussed in hushed or hopeless tones at most places I've worked. There are reasons it is avoided on both business and technical sides. Business gets no tangible value (no new features) and extra risk that the refactor breaks something. From the dev side, familiarity can sometimes be strong inertia in a team setting. This is all made worse by the fact that refactors frequently turn into explorations of new tech/patterns. They don't improve things so much move the technical debt to a different area. I have made this mistake more than once.

Refactors like that are investments in the future of a product. So they should be planned in detail -- usually there are a lot of details to untangle. The practical benefits AND downsides should be researched. It shouldn't just be a tech swap. Breaking it down into smaller, incremental improvements is best.

peerreynders • Apr 7 '22 • Edited

Martin Fowler:
"As soon as you talk about refactoring or attention to good design and modularity in terms of professionalism and keeping your code clean and all that kind of stuff you've lost. As soon as you try to make this argument you're screwed. This argument you want to ignore, get rid of it. Instead focus your argument on simple economics: We're doing this to be able to deliver more functionality more quickly. That's the only reason you should be refactoring".

J.B. Rainsberger:
"The only reason to refactor is to reduce volatility of the marginal cost of a feature."

Kent Beck:
"for each desired change, make the change easy (warning: this may be hard), then make the easy change"

Make it work, make it right, make it fast

Red-Green-Refactor:

Red: Write a failing test that verifies expected outputs for a fixed set of inputs.
Green: (Make it work) Write whatever horrible code is necessary to make the test pass. Write code to help understand the full scope of the problem.
Refactor: (Make it right) Formulate the solution now that you have a better understanding of the problem with working tests as a safety net.

People are still referencing Working Effectively with Legacy Code (2004) today

FYI: Michael Feathers is a classicist so he doesn't use mock objects buts relies on wrappers and fakes; some people are under the impression that lack of mocks is a sign of an outdated methodology; in fact it's different schools (Detroit/Chicago (1999) vs London (2000)) of thought - in fact proper use of mocks is a recurring topic of controversy.