Managing Technical Debt in a Cloud-Native Application
Technical debt is the cost of doing additional work caused by choosing an easy, limited or sub-optimal solution now rather than using a better approach that would take longer or cost more money.
The term refers to the work that is necessary to do sometime in the future to rewrite poorly written or incomplete code to remove deficiencies. The more technical debt your application has, the more opportunities exist for spending money and effort to simply bringing the code up to an acceptable level of quality and professionalism.
Technical debt can naturally and quietly increase during the normal process of developing and maintaining a product—every change you make impacts the technical debt of an application. If the work improves the code and removes shortcomings, it reduces the overall application’s technical debt. But if it involves making incomplete changes or changes that make the code more brittle or unstable, then it increases technical debt.
All too often, project development on modern applications involves making incomplete changes that increase technical debt. Time-to-market concerns, staffing and cost reduction strategies and pressure to release quickly cause shortcuts to be taken in the development process. These shortcuts almost uniformly increase the overall debt of the application.
Cloud-native application development processes tend to encourage this. DevOps and Agile programming practices favor short-term changes rather than long-term improvements. Fast-moving business strategies, enabled by cloud-native application strategies, push development teams to do more in less time. All of these tend to increase technical debt.
More often than not, unless a specific process is initiated intended to remove it, development processes almost always increase technical debt.
Managing Technical Debt
How can you manage technical debt in a cloud-native application? There are several steps you can take.
Strategy One: Strive to Resolve Some Technical Debt in Each Sprint
In every sprint, the amount of technical debt can vary; sometimes decreasing and sometimes increasing. The more quick-and-dirty projects you do, the more you increase your technical debt. The best way to manage this is to strive to reduce it little by little in each sprint. That means actively executing debt reduction tasks during every sprint. And, if a particular sprint has a quick-and-dirty project that is important from a business standpoint, make sure to factor in debt reduction tasks around it and invest in them more in future sprints.
Strategy Two: Be Careful Matching Expectations to Deliverables For MVPs
Make sure to be thoughtful about what you are and are not doing to complete a minimum viable product (MVP). Matching deliverables to real expectations is critical. When expectations don’t match actual delivery plans, technical debt is created. This means that MVPs should be treated as precisely what they are: Minimum viable products. They are not acceptable completed projects, but simply a step along the way toward a completed project. Unfortunately, too many companies will deliver on an MVP and then move on to a new, unrelated project. This tends to grow technical debt significantly.
Strategy Three: Focus on Core Infrastructure Issues Early
Early in the product development phase, feature creation is the primary focus. What features do we need and how quickly can we produce them and make them available to our customers? This philosophy tends to put essential infrastructure projects on the back burner. This means important projects—such as building a scalable architecture, building in high availability and making your application secure—often become secondary concerns and are set aside.
The problem is these issues tend not to be visible until an actual crisis occurs—often much later. So it’s easy to fall into the trap of not worrying about application scalability until you have a scalability problem. And taking that sort of wait-and-see attitude with security can be seriously dangerous.
Availability, scalability and security issues often form the backbone of an application’s technical debt. Focusing on these issues early in the project development phase reduces the cost, complexity and impact on technical debt.
The Negative Impact of Technical Debt
Technical debt is not necessarily all bad. Sometimes business realities require us to implement a more straightforward solution now instead of delaying a longer-term implementation until later. This allows you to get a product or feature out to customers earlier and gain valuable customer feedback that can help adjust the requirements as you complete the implementation.
This is analogous to taking out a loan to purchase a house. You are willing to pay interest on that loan (the technical debt) in exchange for having a home to live in now. But if you borrow too much money for your home—more than you can effectively manage to pay back in a timely fashion—you can create a financial problem for yourself. Or if your spending habits cause you to end up with huge credit card balances that you can’t effectively pay back, it will hurt your financial future considerably. So, too, with technical debt. Suppose you end up creating more technical debt than you can effectively manage. In that case, you become overwhelmed with the debt and it gets in the way of you being able to produce new and exciting features for your customers and business.
When debt reduction projects stop or slow down and quick-and-dirty projects rule the day, you are setting yourself up for a problem. Technical debt can quickly become the dominant concern in your team, and you can spend little to no time on valuable business or customer features. Unfortunately, when this happens, your technical debt is too large to control.
