01 Wasteful Applicative Evolution, 03 The Change Factor

Coming Full Circle: Timing Refactors

Reading Time: 3 minutes

We ended the previous chapter questioning ourselves whether refactors can be avoided. In order to understand if it is, let’s play with their timing.

As we’ve discussed on the Evolution to a Monolith a refactor is done too late because it takes us time to notice its need. Let’s do something counterintuitive and decide to always refactor and to start doing so as soon as possible (day 0). Let’s see what we come up with in this really theoretical situation.

The Velocity decline of our newly created application supposedly looks like this: 

When an application is first created an effort is invested into its first setup/init (new git repo, installing packages, CI/CD pipelines, etc). For the sake of simplicity, let’s presume our Velocity will be zero because it’s not purely invested into moving the business forward.

Once the init phase is done, we’d be developing our Minimal Viable Product (MVP). Our Velocity would be around its peak (theoretically) because nothing exists yet. There is no past to Change or at the very least our code size is at its lifetime minimum.

The development of the MVP is a matter of weeks. Afterwards comes years the continuous development that follows it, whether its new features or maintenance. That’s when the decline starts at an unknown rate. By the way, we only presume the decline is linear.

In the previous chapter we mentioned there are two kinds of refactors.

The first kind, where we ease up our coding, has a prerequisite. It requires us to know better, to know what we could have done better. We need to evolve as engineers, to gain hindsight on the work we’ve done on our application. That requires time itself to pass. 

The second kind, where we make it easier to extend our application, also has a prerequisite. We need to better know what our application does. Whether a Change was valuable or done correctly is a presumption until the Change is actually done and delivered. That is feedback we need in order to know better. That requires time itself to pass.

As time passing is a requirement, it’s impossible to both code and refactor at exactly the same time! So if time does not pass and we can’t know better, all that is left to do – is to do our best to the best of our knowledge. Doing our best at any given time, would not avoid refactoring, but would push it further into the future as possible. Which is the only thing we can do in evolutionary processes. 

Let’s say time did pass, enough time to know better. A week or two. We are in the now again. Now is the time to do our best. But now is never the right time. Which is where we started this journey of Wasteful Applicative Evolution. Because now is never the right time, instead we do nothing. Nothing speeds up the evolutionary processes. Doing our best slows it down.

What is our best and how to avoid nothing? We would see an answer to this in the next series (“The Inevitable”) where we would be discussing the Beneficial and Eventualism frameworks.

Thank you for reading this series.

Leave a Reply