This is second part of series of articles about “Complete Set of Tactics for Reducing Tech Debt: Lessons Learned from 14 Years of Building Java Enterprise Systems”.

• Part 1: “The Beginning of a Big Project“
• Part 3: “New Beginning with Microservices Architecture“.

Due to the growth in LT and TTR, the client started to question our ability to deliver on time and within budget. To address their concerns, they requested an external audit of our system in late 2014/early 2015. We were initially worried that this audit was a sign of a lack of trust from the client. However, the audit was performed fairly and focused on the value for the client.

They confirmed that we followed architectural guidelines for enterprise software, and the monolithic architecture was the natural and best thing to do for the system at the current stage. However, they also pointed out that the system architecture should change to be able to support future growth.

Convincing the client to invest in reducing the tech debt was really hard, and such a comparative technological audit helped in pushing the needle.

However, the client was still refusing to invest in tech debt reduction. We enforced simple rules to refactor the system during the delivery of the project.

This required a cautious approach because refactoring can easily destroy the stability of the whole system, and an engineer who started it can be lost in this mission.

We set a few simple principles, which we called “No Harm Refactoring Principles.” Refactoring Principles.” We will discuss these principles in a separate article linked in this ebook. The audit performed by external engineers was at the end a helpful experience for our development team. It taught us the value of comparing an existing system with other systems of similar size and source code health parameters auditing. Our company now offers Comparative Technological Audit, as we believe that it can support existing teams’ decisions and give new strength to their arguments in front of clients or supervisors.

However, the main reason why tech debt had grown was due to the amount of business logic that was influencing the stability of the whole system because the logic was going through several different modules in the system, resulting in coupling them tightly. The audit confirmed that we needed to change the system architecture (we call such a service: Migrate Monolith to Enterprise Software) to support future growth, but the client still was not ready to make that investment.

In 2013, we confronted the manager of our client with an estimate of six months to reduce the tech debt of the existing solution. We conveyed that delaying this investment would only result in that number increasing significantly, not in a linear manner. While the No Harm Refactoring Principles proved beneficial for small improvements, significant architectural changes were not carried out due to their impact on the delivery of new features.

However, the situation changed in 2016 when a new manager joined our client. Armed with the results of the Comparative Technological Audit, the new manager saw the class diagrams resembling spaghetti, accompanied by decreasing MTBF, increasing LT, decreasing efficiency, increasing TTR, and increasing TTFC – all critical metrics were underperforming.

The audit process taught us the value of comparative technological audits in supporting decisions and strengthening arguments. It also highlighted the importance of addressing tech debt early on and the challenges of convincing clients to invest in reducing tech debt. The impact of management change can bring new perspectives and opportunities to address tech debt and improve software development processes.

In 2016, we were presented with an opportunity to improve the system architecture of a six-year-old project suffering from tech debt. Over the course of several months, we were attending external events and meetups to gain knowledge, and concluded that microservices architecture was the way to go. After internal workshops, we became most intrigued by the Event Storming approach and decided to conduct one with our Client.

Brandolini’s profound knowledge and experience in Event Storming left us feeling as if we were playing in the world league. Following the workshop, we gained a comprehensive understanding of our business logic and extracted the core domain called “Banks”. This led to the extraction of microservices and the use of Docker and containers. The Event Storming workshop that followed introduced us to a new era of our system – microservices.

Comparative technological audits and event storming are powerful tools in managing tech debt and improving software development. By conducting audits and leveraging event storming, companies can gain insights into the existing system’s strengths and weaknesses and identify opportunities for architectural changes and the introduction of microservices. These strategies can help mitigate technical debt and create a foundation for more efficient and scalable software development.

In the context of Java development, managing technical debt involves adhering to best practices, applying appropriate design and architecture patterns, and leveraging frameworks like Spring and Hibernate. Continuous monitoring of system performance, load testing, and utilizing tools like JProfiler can help identify and address inefficiencies. Comparative technological audits and event storming can provide valuable insights into the system’s architecture and potential areas for improvement. By adopting a proactive approach and investing in tech debt reduction, companies can mitigate technical debt in Java projects and ensure long-term system optimization

Read More:

• Part 1: “The Beginning of a Big Project“
• Part 3: “New Beginning with Microservices Architecture“.