All technical debt should ideally be eliminated; however, product iteration cycles END. Executives demand certain things on certain dates. These deadlines are a part of the coding process - there is a time component that works right alongside syntax, form, elegance and function, like it or not. No matter how agile you want to be, in order to make a realistic living as a tech pro, you are going to have to make some technical debt compromises! The question is how to minimize and strategically locate this debt so that it actually works in your favor.
Identifying Mission Critical Points
The first step to a strategic use of technical debt is to identify the places in which technical debt will cause an unacceptable problem. Prioritizing mission critical points allows your team to reduce or eliminate technical debt in the places where it is most relevant. In these prioritized areas, your programmers can go crazy with ideas to improve upon the efficiency of your default function libraries, reduce dependencies left and right, and create the most elegant code possible. In other less important areas, you save time by reducing the effect that inefficiency in that section has on the performance of the product as a whole.
Improving your project backbones will likely reduce the redundancies and dependencies that you face in ancillary functions, especially if you have to build additional features from SDKs because of a time crunch. You can also identify which sections of your project are in most need of creative customization efforts and which can be put together, at least partially, by pre-built assets.
Good Debt vs. Bad Debt
Programming is like finance: There is good debt and bad debt. In the world of money, debt that leads to an income stream is good debt. Bad debt is consumer debt that you incur on a depreciating asset like a car or a dress. Are you buying something that pays you back with your technical debt?
For instance, you may be able to buy your team some time by incurring some technical debt on the front end if a client is requiring a proof or a build too early. The gaming industry is full (perhaps too full) of 1.0 releases with day one patches. The dev team is usually under the thumb of the distributor in that instance, and in the AAA world, on the hook for tens of millions of dollars. The worldwide marketing campaign has been hyping the September 15th release date for a year or more. The game is coming out on September 15th, technical debt and all. This is good debt, because if the release date gets skipped, there won't be any audience to create the day one patch for (No Man's Sky, anyone?).
Do not begin accumulating small technical debts that have no "repayment plan." This is the equivalent of the high interest credit card in finance. Make sure that any debt you leave has a plan for optimization and a timeline to completion. Yes, everyone wants to be agile and never stop improving - "completing" something is an antiquated concept. We know. Back in the real world, your competition will be putting hard dates in their process outlines.
Product Design Debt vs. Technical Debt
Make sure that you are not creating product design debt instead of technical debt that you can reduce over time. Product design debt is debt that occurs when you maximize your feature set to its limit. Eventually, the design becomes antiquated, and you have to retool the entire design instead of incrementally improving your program by reducing technical debt. After MySpace was bought by NewsCorp (before its current Viant deal), one might say that it lost its audience because it refused to pay down its product design debt. Facebook introduced a setup that was less conducive to spam, and people responded by moving.
By definition, technical debt is debt that remains agile. Iterations are created with an eye to the future while optimizing for the present. Trends must be taken into account well before they become mainstream. As a matter of fact, technical debt becomes an advantage in this instance because you spend less time on functions and features that you know will become antiquated in a few months. The time that you save here is spent creating that feature's replacement.
Embracing Technical Debt
Your engineers are not creating technical debt from lazy programming. Stop blaming them for it! Make sure they have a plan for reducing the debt that naturally gets created because of timelines and deadlines. As long as your team has a way to increase the efficiency and performance of a program so that your client consistently remains competitive, people will keep giving you the time that you need.
Technical debt gives you a chance to take full advantage of the time and talent that you have. You can expand on ideas with less pressure and create ongoing business for your team. Keep in mind the ways to use technical debt strategically, and you will soon find that there is no need to eliminate such a good friend!
