Technical Debt is, “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.”
Rethinking Technical Debt
Most of us have an idea of what Technical Debt is when programming, but how often do we think about what it really means or plan on how we deal with it? While the term allows us to describe an
often common situation in our projects, it does not always help us solve those problems. If we change the way we think about our technical debt then I believe it will be easier to think about how we deal with that debt.
What is Traditional Technical Debt?
According to Technopedia.com, Technical Debt is, “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.” This definition implies that technical debt only occurs when we take shortcuts or implement solutions we know to be deficient. An important aspect of this concept is that these easy to implement solutions make it harder to maintain or update the code later. While this is the easiest way to think about technical debt, it also lulls us into overlooking much, if not all, of the technical debt we really have.
How Should We View Technical Debt?
Technical debt is the combination of every decision that goes into a project. From the choice of language and tools you use to implement projects, to the specific business considerations that drive what the project does; everything has debt associated with it. Taking shortcuts to get results faster can have high debt values while other choices such as business decisions to language choices may have low debt values. The key thing to realize is that all decisions have some amount of technical debt that may make updating or maintaining a project harder.
Dealing with Technical Debt
Dealing with technical debt is best dealt with like financial debt. You need to identify a project’s debts and then prioritize those debts based on the impact each has on the project. Once you have prioritized the debt you can then start to pay it down by refactoring to remove or reduce the overall debt. Doing so on a regular basis, like paying bills or a mortgage payment, will help keep the debt in check.
Examining a Hypothetical Scenario
For review, let us look at the following hypothetical project. Project MyExample is a mobile app developed with Java for Android devices. Users will be authenticated using the standard Android Authentication Service. Once logged in, users can resize and share photos on their device with comments to a website. In order to meet a deadline the application resize code was copied from another project and can only handle a single format.
The obvious debt here is the resize code that only supports a single format. Depending on how that was implemented it may require rewriting the entire resize process to handle additional image formats. However, there is much more here that could become problematic in the future. In the future, if the business supporting this app wants to move to iOS mobile devices then a lot of the decisions made prior all become significant technical debt; starting with the language and most likely including the user authentication services chosen.
While this simple example would likely just have two projects, one for each platform, this in itself is opting to support more technical debt as now two projects need to be maintained and updated. A cross-platform language could be used to allow for developing the code once. Alternatively, you could use API’s or microservices to move the business logic into shareable components or services. Even using common design patterns within the code could alleviate some of the problems.
All of these solve problems but also come with their own type of technical debt. Not all debt is bad and being smart about what debt you carry should be what is important. The key is to think about how each decision affects a project’s complexity and maintainability.
Rethinking what we view as technical debt can allow us to better see the cost of the decisions we make. With a little discipline it can then be easier to address the problems in a meaningful way without getting overwhelmed. Taking an easy implementation now to meet a deadline is obvious debt that can be expensive and add up quickly. Other decisions made may be less obvious debt but could be just as prohibitive to the additions to or maintenance of a project.