Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
As a product manager, I dread the moment a developer says, “Wait a minute; I need to refactor …” (I wish it was just a minute). Something that should take two days starts taking three days and then a week. Over an application’s lifetime, the app starts accumulating technical debt. At that point, innovations become a smaller and smaller percentage of the work due to the vast efforts invested in the extra time required to support new developments.
It is okay and natural to get into technical debt. As in finance, some people will take out loans to invest in something because they know that later they will be able to sell it for a higher price and pay off the loan with ease. Same with code. You take on technical debt because you want to develop the application faster and get the product or updates out as soon as possible. But in the end, the technical debt has to get paid. This creates friction between R&D and product, and although we both understand at some point that modernization is needed, it is difficult for the team to quantify. Due to all the long cycles, the complex QA, the increasing number of bugs and security issues, engineers start to feel frustrated. And as a product manager, I also feel frustrated when dealing with missed deadlines and inflated estimations.
It’s not that we don’t want the developers to be happy and to invest in the code (and, let’s face it, in their own mental health, too), but we never know how much time and money is actually spent on technical debt versus how much is reallocated to innovation. For me, that was always a big question, but I never managed to move the conversation from, “I have a feeling,” or “The code looks ugly …” to “For every $1.00 I invest, X% is dedicated to maintenance.” How do we stop guessing and feeling we are in debt and actually start measuring it? And once we make technical debt tangible, when and where do we start modernizing?
Every application’s innovation cost is affected by its level of technical debt. It’s important to determine how much money invested in the application is put toward innovation and how much is used to repay technical debt. In addition, there are classes of debt that add more complexity and risk overall.
The newest versions of a monolithic application’s framework can be tagged as modern, aging or unknown (if the jar file isn’t found). This adds another layer of information when deciding what a modernization effort would entail and helps you focus first on aging frameworks that pose the greatest risk to enterprises due to the accumulation of technical debt and security concerns.
Complexity, Risk and Debt
The complexity of an application is determined by the degree to which class dependencies are entangled, reducing the level of modularity. A code risk relates to the length of the dependencies: How might a change in the application affect some of its seemingly unrelated components?
These two metrics affect the architects’ ability to decouple functionality and create independent, isolated microservices in the future. At the end of the day, that is what forms the overall technical debt. Using the average of these three metrics, we can further prioritize applications in the portfolio. This provides insights into immediately actionable areas, such as our next metric.
The process of modernizing takes time and money and, unfortunately, is a high-risk and often unsuccessful project. To make this process successful, it is first necessary to understand the cost of innovation, the complexity of the application and the risks involved. With these metrics at their disposal, R&D and product are well positioned for a comprehensive, data-driven conversation about modernization.
