Reasons Not to Refactor

I spent about a 12 year period of my career doing triage and app performance work. What struck me was how often the core problems were architectural. Either the design was bad from the beginning, or the requirements had changed so dramatically over time (think scaling, for example) that the architecture no longer worked. I bring this up because while I saw a lot of questionable code, at the micro level it really didn't matter. Sure it could have been refactored and improved, but that would have been essentially diminishing returns. Often the improvements that were needed would have been so painful that rather than make them, I watched companies spiral around either throwing hardware at problems or replacing the application entirely because that kind of Bandaid rip was deemed "easier" in the overall politics of the corporate world. So point being - sure, refactor what you can, but don't get too hung up on things that ultimately won't matter.

Simple and brief rules are more successful in practice than long and complicated rules.<p>I feel a briefer and more-to-the-point <i>&quot;When To Refactor&quot;</i> guide is to ask the following questions <i>in the following order</i> and only proceed when you can answer <i>YES</i> to every single question.<p>1. Do we have test coverage of the use-cases that are affected?<p>2. Are any non-trivial logic and business changes on the horizon for the code in question?<p>3. Has the code in question been undergoing multiple modifications in the last two&#x2F;three&#x2F;four weeks&#x2F;months&#x2F;years?<p>Honestly, if you answer <i>NO</i> to any of the questions above, you&#x27;re in for a world of hurt and expense if you then proceed to refactor.<p>That last one might seem a bit of a reach, but the reality is that if there is some code in production that has been working unchanged for the last two years, you&#x27;re wasting your time refactoring it.<p>More importantly, no changes over the last few years means that absolutely no one in the company has in-depth and current knowledge of how that code works, so a refactor is pointless because no one knows what the specific problems actually are.

Everyone talks about refactoring code. What I don&#x27;t see enough discussion on is refactoring <i>tests</i>.<p>It&#x27;s a constant battle at work, and I tend to be firm with: &quot;If the test is working, no matter how horrible the (test) code, leave it be.&quot;[1]<p>For regular code, we rely on tests to validate our refactors. With test code, we don&#x27;t have that support.<p>If you have a bunch of tests that could do with a refactor, and your motivation is that you need to write more tests, then set up whatever abstractions you need and write the new tests, but <i>don&#x27;t</i> touch the existing tests! If you really want, you can overtest: Write new tests with your refactored code that test the same thing as the old ones. It&#x27;s OK to test the same thing multiple times (when testing is cheap).<p>About a third of the time a coworker looks at my tests and refactors them, he makes an error - the most common one being not testing what the original test meant to test. See, the reason he wanted to refactor was that the original test was hard to follow. And <i>because</i> of that, he failed to interpret it correctly and failed to properly reproduce the test in his refactored code.<p>I then have to code review all his refactors. I have to spend time to figure out what my difficult-to-understand test did, and confirm he didn&#x27;t introduce bugs. It&#x27;s very, very tiring. And for what?<p>And he&#x27;s not a newbie. He&#x27;s as good at SW as I am. Plenty of experience. If <i>he</i> gets it wrong, I expect most people will get it wrong. With a higher error rate.<p>This is the one case where I say: &quot;Feel free to overcomment.&quot; If you took a long time understanding a given test, write out what you learned so that the next time you read it, you know what it does. I&#x27;ll be happy to code review <i>that</i>.<p>[1] Unless you are the original author of the tests, and they are still fresh in your mind. In that case, refactor all you want.

&gt; If we’re embarking on a change that is not really refactoring (for example looking at a bug or an adjustment after a third party change), we can’t fix it with refactoring.<p>Funnily enough I did once fix a bug through refactoring. IIRC it was some intermittent race condition in some async code that I just couldn’t figure out, so I rewrote the code to do the same thing but simpler and the problem disappeared. I was too tired and relieved to continue figuring it out why it was originally broken.

If it won&#x27;t impact your margins or the customer&#x27;s willingness to pay for the product then it is difficult to justify.<p>I&#x27;ve been involved with (and responsible for) many &quot;developer aesthetic&quot; refactors over the years. They feel good in the moment but after blowing 2-3 weeks with regression testing, hot patches, etc., you start to wonder if it was all worth it.<p>There is stuff that is properly nasty and needs to be dealt with, but if you are spinning your wheels on things like namespaces being stuck on old company&#x2F;product names, I would just give it up and move on. The average customer cannot see any of the things that frustrate us unless they are being done <i>very</i> poorly.

&gt; We often reach a point during refactoring where it seems like there is an easy improvement that applies to almost all cases. It’s usually better not to impose additional abstraction if it only matches “almost” all cases.<p>Need to nit-pick on this one. There are design patterns, depending on your programming paradigm, that enable you to de-dupe the common stuff while allowing for all of those little variances to do their own unique thing without duplicating anything.<p>In OOP the Template Method pattern comes to mind.<p>I would even go so far as to say that the &quot;almost all cases&quot; problem is such a common problem in software development, that the patterns world has come up with various solutions to that which are intended to simplify, not complicate.<p>I&#x27;m sure there are concrete examples where there are no good pre-existing solutions, and there are often examples where cures can be worse than the diseases and you need to make a judgement call. But don&#x27;t give yourself an excuse to duplicate code because you don&#x27;t know how to de-dupe in the &quot;almost all cases&quot; scenario. That&#x27;s a very solved problem.

Refactoring depends heavily on circumstances. I&#x27;ve seen terrible attempts over my career for all the reasons other people have and will mention here.<p>But I&#x27;ve also seen huge successes. Usually it boils down to &quot;what are you trying to accomplish?&quot; against current code and architecture. I&#x27;ve seen targeted refactors of micro-service code, including language shifts (eg python -&gt; java where threading improved things a lot in that use case), as well as targeted shifts of code to AWS Lambdas, where execution scaling also benefited the use case. But in both examples there was a clear benefit, execution plan, and way to measure success.<p>When you start refactoring large mono-app code bases for nebulous, hard to measure reasons then the risks are much higher (and that&#x27;s even before scope creep comes into play). This gets even worse if the reason the current code is no longer desirable has reasons (both good and bad) that it is the way it is, and you risk recreating bad code (this was mentioned in the article) into new bad code. Also, migrations to new code can suck if the underlying dependencies, including data(bases) is just as much part of the problem?

One more consideration is whether a team of people have invested time building a mental map of the current code. Perhaps some rearrangement would be better, faster, clearer, or have some other virtue. But that benefit has to be balanced against invalidating the mental caches of all the other team members.<p>More than once, I&#x27;ve studied code and become adept at maintaining it. Then someone &quot;refactors&quot; everything and I have to invest the effort again. After a few cycles of this, I lose interest in ever seeing the code again. At that point, I can no longer orient a new dev to the code because I&#x27;m no longer oriented myself.

I like these reasons.<p>I will offer some caution on rules for rejecting a proposal. Often times, the number one reason to do something is that there is energy there to do it. If you can take that energy and apply it somewhere else, by all means do so. All too often, suppressing some energy stops all effort.

&gt; <i>There’s no benefit to improving code that never changes, even if it is highly complex.</i><p>Only if you don&#x27;t care about being able to understand and debug the code in the future!<p>And even then it&#x27;s if you&#x27;re confident in predicting how much code will or won&#x27;t need to change, which, well...

Peeves about the items in the linked post:<p>&gt; 1. The change is not really a refactor<p>Is anything ever really just a refactor, though?<p>&gt; 3. Another refactor is already in progress<p>Ah, but - in large and poorly-maintained codebase, it is always the case that some refactoring is already in progress, likely stalled for weeks, months or years as priorities have shifted without it having been completed.<p>&gt; 4. The code is unlikely to change<p>If the code is unlikely to change, there&#x27;s a good chance you might want to refactor it out of your repository anyway, into some low-frequency-of-changing library.<p>&gt; There’s no benefit to improving code that never changes<p>Oh, there are lots of benefits to improving code that never changes! And that&#x27;s because other code _uses_ the code which never changes. And if originally the use is clunky, but you manage to improve it by your refactor, youve&#x27; done well indeed.<p>&gt; 5. There are no tests<p>A repository which lacks test coverage is extremely likely to be in dire need of all kinds of refactoring. Waiting until someone (maybe even yourtself) writes tests for most code, before doing anything in the mean time - well, it basically means giving up on yourself.<p>&gt; we can start by writing some tests!<p>Well, that&#x27;s nice, but - if we do that, then no refactoring would get done, and we&#x27;ll have to write code based on ugly and unweildy older code, which only adds stuff to refactor later. Plus, who&#x27;s to say the tests don&#x27;t fail _already_? :-(

It&#x27;s all solid advice but that exchange in #5 that the author found delightful, drives me bonkers. If you talk to the people on your team like that, you&#x27;re not being helpful, you&#x27;re being an a-hole. I realize its just making a point in the context of the article, but this industry seems to collect pedants, so it seems worth pointing out as an anti-pattern.

Does anyone really get time to refactor anything these days? Seems like (at least where I&#x27;m at), everything is go-go-go, feature work.

I have one reason to refactor that&#x27;s served me well. Does the code exhibit ongoing edge&#x2F;corner case bugs, which are attributed to the implementation not being factored in the first place? Another sign of this situation is exhaustive test cases which combine factors as they can&#x27;t reliably be tested in isolation. Distributed logic is another common pattern, where a new feature is made by sprinkling bits of logic here and there, just so, and it all seems to do what&#x27;s required. You know the kind, where onboarding a new person might lead to the discussion of how this section of your Rube Goldberg contraption works. A fancy way to this world is a poorly designed and maintained home-grown DSL.<p>Continuing to build on such a &#x27;foundation&#x27; is madness that spirals to code red situations: stop-the-world, no feature development, until shit gets stable.

The default-oriented answer to #2 is to pass the rows through some function that applies the default to &#x27;loud&#x27; if loud is undefined. That&#x27;s really pretty code and avoids the complex if-statement which is a universal bad smell.

&gt; Instead of “refactoring” without tests, we can start by writing some tests!<p>I agree with this but I have always struggled with putting it into practice. Good code is easy to test. Often, I want to refactor to make it easy to test.

When working with git it’s better to split refactorings, bug fixes and features per commit or merge request (if you squash) else your git history will be not so useful anymore.

There are two conflicting rules of thumb floating around here<p>1. If hasn&#x27;t changed in a long time and no business requirement on the horizon will force it to change, don&#x27;t refactor. 2. Code is read more than written, so optimize for readability.<p>(1) can only be followed to the detriment of (2), unless you add the condition that the code is <i>also</i> code which developers never need to read and understand to implement other features.

another reason to not refactor is management will start out supportive of it but some weeks in they will wonder wtf their engineers are doing all day and why aren&#x27;t they building the new pile of stuff they want built yesterday.

&gt; <i>“Before we can add tests, we need to refactor.” - “No.” - “Refactoring th–” - “No.” - “Refa–” - “No.”<p>What to do instead: Instead of “refactoring” without tests, we can start by writing some tests! Writing new tests will help us learn about the code. After that, we can come back to refactoring.</i><p>I assume the author means system tests here? Because it&#x27;s absolutely possible to have code that is so entangled that it&#x27;s impossible to write self-contained unit tests before, well, refactoring the code.

My top reasons not to refactor:<p>1. My boss won&#x27;t let me. The usual excuse: &quot;Too risky... there are other priorities... and besides, where are those performance improvements you promised me? We don&#x27;t pay you to make the code pretty.&quot;<p>2. Boss of group which owns some of the code I need to refactor won&#x27;t let me: &quot;Too risky... we have other priorities... have your boss bring this up in the next [bogus] meeting&quot;<p>3. Other developers get panties in a bunch over a tiny refactor (semantically) but which involves changes to names in a lot of files.<p>4. Knowing that if I&#x27;d start this refactor I will not be able to resist another refactor until I&#x27;m basically refactoring people&#x27;s entire code to look quite different.

Well, yeah, that example decreases symmetry.[0]<p>0. <a href="https:&#x2F;&#x2F;bensguide.substack.com&#x2F;i&#x2F;144306439&#x2F;local-symmetries" rel="nofollow">https:&#x2F;&#x2F;bensguide.substack.com&#x2F;i&#x2F;144306439&#x2F;local-symmetries</a>