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.
What do home ownership and leveraged buyouts can teach us about how to use technical debt to our advantage in Scrum? How can we sleep soundly at night when we have accumulated mountains and mountains of technical debt? When is good enough good enough and when are we just deceiving ourselves?