Martin Fowler defined refactoring as a ” disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior”. In the days of Agile development where code is delivered after one or two-week cycles, you start quickly to deal with “legacy” code, what was known as “maintenance” for projects that had longer delivery time frames.
In the world of software development, dealing with legacy code is often a necessary evil, especially for successful, fast-growing companies. But how do Agile teams tackle this challenge smartly and sell the idea of refactoring to the business?
Technical debt is a metaphor coined by Ward Cunningham in 1992. This concept refers to the work that needs to be done so that a software development project could be considered as “complete”. Could you try to measure your amount of technical debt? Could you use some tools to do this? These are some of the questions that this article explores.
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.
Scrum Expert Copyright © 2009-2026 Martinig & Associates