I’ve had several interesting discussions over the last few weeks about the topic of “Technical Debt”.  Besides the negative connotation of the term, it is used to refer to a software design that was not fully implemented to meet a given set of requirements.  Another way to explain it is that developers “cut corners”.

Wikipedia defines Technical Debt as follows:

Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future.

Source: https://en.wikipedia.org/wiki/Technical_debt

In contrast, the Agile methodologies prescribe that software should be built in an evolutionary fashion.  This suggests that designs are crafted for only what is required at the time the software is written.  

This leads to an interesting crossroads.  In the early phases of writing a website, it is acceptable to optimize performance for a few hundred to a few thousand users as part of the requirements at that time.  The development team does not know the full scope of the traffic the website will receive, and performance can be tuned at a later date.  When visitor traffic patterns change, performance concerns start to become more noticeable.  

How should an agile team address these concerns?  Is it technical debt, or have the requirements for the system changed?