One of the great things about the technical debt metaphor is that it expanded the conversation on software entropy and complexity to include the business that software is used by and maintained for. The simplest understanding of technical debt is that it is the result of a lack of technical rigor - whether it be voluntary or involuntary. Regardless of how it was incurred, technical debt has to be managed at one time or another. This should be done from a strategic standpoint with support of the backlog and help of the client.
The creation of debt itself, contrary to popular belief, is not always due to a lack of skill or discipline. At it's best, it is created to meet a business need that otherwise could not be met. So when starting the discussion of technical debt you have to aware of the different levels of it, and the costs associated to each level. Martin Fowler, for example, states that missing a payment on a credit card will end up costing you a lot more than missing a payment on a long term mortgage plan. By using personal debt as an analogy to technical debt, it helps to identify debt in various domains.
Core domains of your system should be in line with agile development practices (they should be testable, have low coupling and high cohesion) so that you can enact change quickly and easily. However, utility domains, similar to the long term mortgage example, can handle more debt as they are less critical to your application.
Keeping a technical debt backlog can be a great way to track your debt, but keeping your technical debt in the product backlog makes more sense. Firstly, these debts belong to the product and will therefore affect its total cost of ownership. Secondly, it is easier and less confusing to put everything regarding the product in the same place. This simplifies tracking everything related to the business, product, and IT. Once the technical debt has been listed in the product backlog, any decision regarding it should be business oriented: i.e. what are the costs, risks, and urgency associated with leaving the debt as it stands.
This is particularly the case with start ups where paying debt right away isn't the most pressing issue on the schedule - gaining a customer base and building your product/market fit. Debt is also usually ignore in an end-of-life system. These two scenario's of ignored debt are driven by business needs not technical ones.
However, when you're not in the start-up or obsolete phase of your product, short term objectives can't be driving your strategy. Just as when you buy a car, you don't simply expect that the costs associated to it will be the sticker price. Maintenance is necessary in order to ensure you get all that you need out of it. This is the same when developing software.
To read the full post visit here.