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.
Technical Debt is defined as the eventual consequences of poor or evolving software architecture and software development within a codebase. In a blog post published for the Software Engineering Institute (SEI), Robert Nord has provided the keys points discussed in a seminar Managing Technical Debt in Software Engineering, an event that discussed both the past and the future of managing technical debt.
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.