Technical Debt is Social; it is the Price of Learning by Doing

Technical debt is not solely a measure of poor engineering, but can also be the price of learning through practical software use, according to Xin Yao's presentation at GOTO Copenhagen. Yao cited Ward Cunningham, who defined debt as "not-quite-right code." While debt may seem negative, it can serve as a deliberate business strategy.

By releasing imperfect code, companies can gain valuable user and business feedback, generate revenue, and advance the project. Debt is essentially the price paid for learning by doing. Yao emphasized that technical debt arises when software is built with incomplete knowledge. Releasing software allows teams to test their assumptions against reality and refine their understanding.

Once this learning has been incorporated, the team must address the debt to keep the software aligned with the new knowledge. While debt can be a strategic communication tool, it is important to recognize its value as a mechanism for enabling learning. The balance between delivering features and preserving future options is crucial.

Delaying design commitments allows teams to preserve options and adapt to new information. Technical debt becomes visible when software no longer matches the team's evolving understanding, turning good knowledge into debt. Artificial intelligence introduces a new challenge: as code is generated faster than teams can understand its behavior and implications, the debt becomes more complex.

Teams must not only address poorly written AI-generated code but also ensure that the software's actions align with their understanding and adapt to the changing domain and architecture. Paying off technical debt is no longer just a technical task but a sociotechnical challenge that requires close collaboration and continuous learning.