Menu

Fixing the monolith

Large companies that built up their technical debt for a long time, focusing their development capacity on releasing new features, find an impasse when they try to implement Continuous Integration or Continuous Development strategies. Coupled processes, shared databases and lack of proper documentation make self-provision, creation of environments and test automation an endless chore. Instead of several independent components, they host a monolith.

The moment of realization usually comes when a new project starts, and the assigned team starts setting up a workable integration context. Confronted with the task of finding the minimum amount of elements required to arrange the environment, the answer seems to be “all of them”.

Having deadlines to meet, the teams take ownership of their own R&D instance, and add to their chores the maintenance tasks. This means that every group works isolated from each other, and “alignment meetings” are created in order to reduce impacts that changes on one element cause on every other component. Release times are increased, testing phases extend longer and longer to cope with the test scenario complexity, and even hotfixes take months to release.

If you work in a somewhat big company’s software department – one that has been around for, let’s say, more than ten years – this picture is most probably a close picture of your daily routine. That is because refactoring is often seen as a “wasted effort”, since a product release holds no new characteristics.

So, consider the following situation: instead of what was previously described, a new team starts working on day one, as the only required component is the connection to a central communication interface. They set up their own separate database, and develop a communication API that every other component can talk to, instead of allowing direct communication to their schema. Test cases can be narrowed down to the application’s specific user stories, and every code commit runs them automatically, reporting their success to the user that generated those changes.

Can the first scenario be transformed on the second? It’s a long journey, but one that is worth investing effort into. On the next series of posts we will attack each individual bottleneck, aiming to untangle the mess that technical debt has turned into.