03 The Change Factor

I don’t know if you had the chance to run into a family member you haven’t seen for 30 years,since he was a small toddler. If you haven't, try googling “Brad Pitt as a baby” or any other celebrity of your choice. Your immediate reaction would probably be “OMG there is no way that this is Brad Pitt! He has grown and changed so much!”. Same goes for this very big Git repository you are working on. When it was first born/created, it was empty. A minute afterwards it had a single “main” file. And now you’re looking at it - and it’s old. It has grown and changed so much. It was not born as a Monolith - it has evolved to one.

This series also revolves around time waste. We've seen it caused by the evolution process of a Monolith and we'll be seeing more of it in this series. But what is time waste itself, what is inefficiency? How do we measure it and what good will it being to remove it?

This time we’d be diving into the actual coding and the code growth, which is another evolution process of its own. We’d see it is another source of inefficiency that causes Velocity drops. We’d be doing this through deep diving into the most frequent and probably the most important event - change. How it is all bundled together through two more important events - the deployment and the revert.

One of the things I admire most about Amazon’s supply chain is the bin packing. When I order several things together, there would be one package waiting for me outside the door. I love efficiency. Furthermore, if I need to return one item I can return just that one item. I wish it was the same with an application’s Bundle.

The longer the interval between deployments is, the more change accumulates, the bigger the Bundle is and the longer the hunt would be and more time would be wasted. The bigger the Bundle is, the more risky the revert is. If the interval is the source of it, we’d try to do some unbundling through shortening it.

We’ve previously described two evolutionary processes, to a Monolith and to a Bundle. We’ve seen that given enough time, they will evolve to it. We’ve dug into our application’s Event Stream to see its causes, actions and events. The third evolutionary process towards a Legacy is on the same Event Stream. The only difference is that the causes and events are external to our application and to us, and are out of our control.

n the previous chapter we’ve explored the consequences of components or systems going into a Legacy state. We’ve seen that it changes into that state due to external events which are beyond our control. This time we’d be diving into the main cause for these external events. Luckily it is probably the only thing that we can all agree on. Time moves forward. Unfortunately, technology moves forward as well. Time and technological advancements are the main cause of Legacy.

We’ve seen three evolutionary processes so far (there might be more). Each and every application has the potential of entering a state of a Monolith, a Bundle or a Legacy. Eventually our application would end up at one of these states, maybe even a combination of them. Afterwards, eventually a Cause (event) would surface that would make you consider a refactor. It could be a technological shift, hiring of new developers or we simply grew tired of it. Once decided on a refactor, it would be a question of when. Between the decision and the execution, the application has entered a state of refactor needed. In the following chapters, we’d be exploring these new states.

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.

To do his best, an engineer would say “I need three days to make this right”. Through a product-only perspective, that would translate into “that’s three days not working on a new feature that is money lost”. There is something to it, because when the business stands still we’d be eventually beaten by our competitors or start losing customers. Question still remains: what is the gap here that causes so much tension between product and engineering?