On Reactivity and Need
Refactoring/Abstracting Code Reactively #
A lot of the content under “design patterns” here has a punchline of “do so-and-so-practice reactively”. That’s a surprisingly nuanced statement to unpack, even without knowing what the practice is. It turns into something like:
“I know it’s painful to suddenly context switch into unpredictable-duration refactoring in the middle of cranking out features, and I know it sucks when deadlines slip, but if you don’t build yourself a culture where you can do that, you can’t get the benefits of that refactoring in any other way, and you certainly can’t achieve them by doing the refactoring up front”.
So why is that? It is almost impossible to predict how code will need to change in the far (weeks+) future. The only winning move is not to play this game. Don’t make your code “extension friendly” or “swappable backend ready” (see “On YAGNI”). Doing so rarely causes anything but confusion and maintainer pain (1)There’s a very small asterisk after that, which you are really going to want to apply to your case but that probably doesn’t, of “unless you are absolutely positive that so-and-so refactor will be needed/pay dividends right away”. More on that in the “Identifying Need…” section below. .
Instead, it’s better to add all those nice, juicy, enterprise-design-pattern friendly refactors reactively when it becomes clear that maintaining code without them will be a bad deal (in bug rates or slowing development time) for the company. At that point, “stop, drop, and refactor”.
People traumatised by bad product roadmapping environments often front-load premature optimization/refactoring/whatever because they’re tired of being told “no, you can’t add that now, it would take too long to retrofit” in reactive situations. I’m sorry to say that front-loading that way doesn’t work, and that the only way out is through: fix your bad product roadmap environment to make it ok to explode delivery times or estimates when it becomes apparent that a refactor is reactively necessary in order to make a requested change properly.
That bold part is bold for a reason. This won’t always be pleasant. Reactively retrofitting a type system or abstract set of interfaces onto code that has been deliberately built without those things even in mind can be really unpleasant, but “reactively” is still the right time to do it. That is because it’s rarely “correctness before the fact vs correctness after the fact”, but almost universally “the wrong understanding of correctness before the fact vs the right one after the fact”.
On the bright side, it’s not as hard as you think to fix that bad environment: the statement “we don’t do any pre-emptive over-engineering, so prototyping is always fast and gets things to customers early; it’s natural for later stage features to be slower to build” can get you a long way.
Identifying Need for Proactive Refactoring/Abstracting #
What, that didn’t convince you? You think that you really can see the future and need to build in modularity/swappability/DAOs for a single model class/repository pattern singleton connection managers for a single query to a single database, because people really will need those things?
Before you follow your gut, get a brutally honest second opinion (your opinion is, unfortunately, too biassed to be trusted here) on whether a given type of change is actually likely in the near term. Not a “yeah, that would be awesome, put that improvement on the backlog” situation, but a “this work is being done as part of a product feature that requires that the capabilities you add to business object X also be added to objects Y and Z by a date this quarter"-type statement. Even when the reaction is positive, do some really strenuous red-teaming of your decision process of the “are we convincing ourselves this is necessary because the end result is aesthetically pleasing, or is it actually necessary in the near term to deliver a given piece of value to the customer and make the company money?"-variety before committing. See “on feelings” for more on that.