However you want to take this conversation, I'd love to hear what it's like in your situation.
For further actions, you may consider blocking this person and/or reporting abuse
However you want to take this conversation, I'd love to hear what it's like in your situation.
For further actions, you may consider blocking this person and/or reporting abuse
Dhanush N -
Michael Tharrington -
Jonathan Brizio -
Ben Halpern -
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.
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:
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.
Very much a normal part of the conversation and encouraged part of the process.
As it is (or should be) a normal part of development that should automatically be done as needed, it isn't really something that gets discussed much
We have freedom to pursue refactoring, but it's honestly not spoken of much.