technical debt

Technical debt is inevitable in Agile software development and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn’t have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes.

This presentation discusses what technical debt looks like, and how easy it is to get into debt in the first place. Then the presenter proposes to put a plan into action to get out of it, understanding that you should consider technical debt as a business problem, not as a tech problem.

Does your technical debt backlog look endless? Are you thinking about pausing feature development to resolve technical debt? Stop. What if you were told that a good chunk of your backlog can simply wait? Technical debt can seem overwhelming when we look at it as a loosely organized list.

This presentation explains how easily obtained version-control data lets you uncover the behavior and patterns of the development organization and manage technical debt. This language-neutral approach lets you prioritize the parts of your system that benefit the most from improvements so that you can balance short- and long-term goals guided by data.

Technical debt is not primarily caused by incompetent developers, architecture astronauts, unrealistic UX people or even stupid project managers. Rather, it is a third-order effect of poor communication. It is a symptom of an underlying lack of appropriate abstractions, which in turn stems from insufficient modeling of the problem domain. In order to avoid technical bankrupcy, therefore, we must improve the way we build our understanding of the problem we are trying to solve.