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.
Technical debt is a well-known concept in Agile software development. Technical Debt is defined as the eventual consequences of poor or evolving software architecture and software development within a codebase. In this blog post, Steve Blank discusses the concept of organizational debt.
Technical debt is one of this great new metaphor that is applied to software development and more specially to agile project management approaches like Scrum. As its financial counterpart, technical debt is not necessary a bad thing as long as you are able to manage it wisely. In this article, Don Reinertsen will help you to put some numbers on the costs and benefits of your technical debt.
Technical Debt has become an Agile catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code. These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions.