Not Born One: Evolution to a Monolith

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.

Born Together: Evolution to a Bundle

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.

Born to Die: Evolution to a Legacy

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.

Time Moves Forward: Technological Shifts

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.

Born to Reincarnate: Evolution of a Refactor

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.

Not a Loss: A Cause for Tension (Appendix)

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?