2 ms·

> Refactoring is (or should be) caused by changing requirements This can be a compelling reason to refactor, but my experience is that refactoring is often cal

> Refactoring is (or should be) caused by changing requirements This can be a compelling reason to refactor, but my experience is that refactoring is often called for without/before any requirements change. Typical cases: - Existing requirements, and interactions between them, are better understood over time, presenting opportunities to serve them better - Current design/APIs are brittle and adapt poorly to maintenance tasks - Resistance to “premature” abstraction/DRY produces large scale redundancies, and consequently increases volume of bugs and time spent versus value of work - Of course the opposite is true, with improper abstractions becoming unnecessarily entrenched and unwieldy - Ecosystem/stdlib improvements make certain areas of custom code obsolete, or more of a liability than they’re worth

crabmusket 4y ago
I'd argue that in all of those cases, the ultimate objective is (or should be!) to serve the requirements. Even maintenance tasks are in service of requirements - if not customer requirements, then internal or environmental ones. Performance can be a requirement too. If requirements aren't changing, the code shouldn't need to change. And if the code doesn't need to change, it doesn't need refactoring.
- eyelidlessness 4y ago
  The objective is to serve the requirements. The code, inasmuch as it “works”, doesn’t need to change. But the cases I enumerated are ones which frequently enable me to better serve requirements than making no changes. If a given bug fix takes N hours because the underlying code is hard to understand and maintain, it only takes a certain multiple of N before it’s prudent to invest some of those hours into making future fixes possible in N minutes instead. At a certain point, precluding changes on principle is directly opposed to serving requirements.
  - crabmusket 4y ago
    I completely agree with you, and I'm not sure how we're managing to talk past each other. I guess in trying to strongly emphasize a position against "pre-emptive refactoring", maybe I'm coming across as being against ever refactoring or changing the code at all?

crabmusket 4y ago

I'd argue that in all of those cases, the ultimate objective is (or should be!) to serve the requirements. Even maintenance tasks are in service of requirements - if not customer requirements, then internal or environmental ones. Performance can be a requirement too. If requirements aren't changing, the code shouldn't need to change. And if the code doesn't need to change, it doesn't need refactoring.

eyelidlessness 4y ago
The objective is to serve the requirements. The code, inasmuch as it “works”, doesn’t need to change. But the cases I enumerated are ones which frequently enable me to better serve requirements than making no changes. If a given bug fix takes N hours because the underlying code is hard to understand and maintain, it only takes a certain multiple of N before it’s prudent to invest some of those hours into making future fixes possible in N minutes instead. At a certain point, precluding changes on principle is directly opposed to serving requirements.
- crabmusket 4y ago
  I completely agree with you, and I'm not sure how we're managing to talk past each other. I guess in trying to strongly emphasize a position against "pre-emptive refactoring", maybe I'm coming across as being against ever refactoring or changing the code at all?