Some economics of refactoring

Refactoring in a separate project is often not the best of ideas 👎 . It might well be the most common form, but it's a terrible idea from an investment point of view. 

Let's look at the investment profile of various forms of refactoring. First refactoring in a separate project; We refactor for weeks or months to make the code somewhat clean again. Of course the business won't see the fruit of the refactoring until it has made us save time developing new features, after the refactoring is finished. 

Compared with no refactoring, the break even comes after many months or more.

Another common type of refactoring is End-of-story refactoring. The value of this refactoring is again reaped when we touch the code again, a few weeks or months in the future. 

While some basic cleaning is called for - encoding "end-of-story" knowledge into the design - any attempt to make the code "extendable" or modular is risky business. It's not KISS/YAGNI and ROI is uncertain. Break even comes after weeks or months.

Now let's look at Preparatory Refactoring, as suggested in 3P ( Protect-Prepare-Produce) https://lnkd.in/eiewkYBe

The return of investment comes directly after the refactoring. It's an investment opportunity we cannot miss! We're almost certain to at least break even, and in the shortest period of time

3P (Protect-Prepare-Produce) acknowledges this and gives us a way of optimizing the ROI while working on stories. Let's see more of 3P and preparatory refactoring, our code will be better off! and perhaps most importantly business people will start to understand and appreciate refactoring 😘 

Quick and Dirty tests, FTW

If we consider solely the refactoring phase: Then what do we care about in tests. What quality do the tests need to be useful to us?

Imagine we could change the tests later, what do we actually care about during the hours/days we're performing some larger refactoring

It turns out we can do quite a few compromises, a lot of the vital qualities of a tests don't matter over a few days, running on a laptop with no other persons reading the tests

Now why would one want to write unmaintainable tests only to replace them later? Well for one it's a lot faster, secondly writing great tests for legacy code is often close to impossible. Given that we'll modify/replace anyway, the question is "What compromises can we make?"

This type of quick-and-dirty tests is precisely the kind of tests were likely to do in a 3P (Protect-Prepare-Produce) approach. The above post will also somewhat lay out when/how/what to do with those quick and dirty tests later.

What about you, are you doing these compromises. Any other compromises?