I was thinking about technical debt in the context of our recent spate of requirements postings on the blog.  Technical debt, from my perspective, does not just apply to software.  We incur technical debt when we implement an easy solution in the short run, as opposed to the best overall solution.  In other words, we have sub-optimized the solution selected.  Experience suggests in many cases we opt to optimize around time at the expense of the best design solution.  This approach does not end at software, but anytime we defer taking the best decision about the product, opting for speed.  We then are on the hook for meeting the financial obligation (debt) that is due.

If we believe that technical debt is associated with any aspect of the product in which we make the trade-off between the optimal design solution and some other consideration such as time, you can see how technical debt has many areas of origin.  This can include things like the requirements for the product.

In more than one of the companies at which I have worked, the requirements documentation served as the basis for the customer documentation.  In some cases, the requirements documentation was held in little regard (email or word of mouth), and the subsequent customer documentation reflected this gap.  Over time, the customer expressed the belief that the product was way too complicated and noted how the documentation that came with the product did not match the actual performance.  With this connection between the requirements and the customer documentation, we can see how taking actions that produce poor requirements will have an impact on the customer documentation.  The poor customer documentation costs the company in customer confusion, additional time spent in maintenance.  You could argue that this cost is at least a portion of the technical debt associated with development decisions when it comes to the requirements.