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”.
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.