Agile organizations find themselves constrained between the need for speed (velocity) and the need for quality. Technical debt is the enemy of velocity. Most companies don’t address technical debt until it slows or halts developer productivity. At that point, it can be very expensive to pay it down.
One of the reasons technical debt is often not addressed is that we think of debt as evil or at least unpleasant. For example, the word mortgage comes from the Old French words mort and gage, which translate as “death pledge.” Andrea Goulet, CEO of Corgibytes, said that companies need to shift their mindset away from paying down debt and toward building technical wealth, away from tearing down old legacy code, and toward deliberately remodeling it. Siemens Healthineers found that talking about creating technical wealth got everyone excited because they were talking about the creation of something positive. Creating technical wealth involves remodeling software to make it run better, last longer, and do more. Technical wealth is about investing in cleaning up code to improve productivity.
You need to understand technical debt to begin building technical wealth. Technical debt or design debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement is used instead of applying the best overall solution. Technical debt can be compared to monetary debt. If technical debt is not repaid, it can accumulate ‘interest,’ making it harder and harder to implement changes later on. Unaddressed technical debt increases software entropy. When you resolve technical debt, you gain efficiency that compounds over time. If a team is not being productive, think about what technical debt is holding them back.
Technical debt happens when there is no core set of well-defined and enforceable design rules for a code base combined with a culture that does not value creating technical wealth. By establishing and iteratively improving design rules, technical debt is paid down and the code base is easier to understand and maintain. Development accelerates and this establishes technical wealth.
To create technical wealth, you must recognize and deal with the hierarchical relationships and interdependencies within the structure of the software. The DSM (Dependency Structure Matrix) characterizes the “topography” of a software design, indicating both hierarchical dependencies and interdependencies among elements.
Focusing on technical wealth means you get a productivity surplus which can be used to pay down technical debt. To build technical wealth, you have to focus on the long-term (software maintainability) and not on short-term fixes.
Some ways to build technical wealth include:
Increasing technical wealth should be built into annual or quarterly roadmaps if you are serious about it. To start a technical wealth initiative, you need to rely on objective standardized units of measure. Some examples are:
These metrics provide visibility into design risk, complexity, and the organization of your software. They will provide a baseline and target risky design areas. Technical debt should be monitored and communicated with teams to find the best opportunities to pay it down and build technical wealth. Continuous monitoring of the design is the best way to drive continuous improvement.
As Marc Andreessen said in “Why Software Is Eating the World,” “More and more major businesses and industries are being run on software and delivered as online services – from movies to agriculture to national defense.” This has led to a huge expansion in the amount of software that is written and included in products and makes changing the conversation from paying down technical debt to building technical wealth vital to all companies.
At Lattix, we have found our software architecture management solution is one of the topics that moves the discussion from the repayment of technical debt to the creation of technical wealth. If you would like to try out Lattix, let us know.
