Technical debt is like the family secret that no one wants to talk about. Everyone knows that it exists, it’s awful, and it makes life miserable for everyone affected by it. However, people are often unable or unwilling to confront it.
The simplest explanation of technical debt is the increasing burden created with each decision to cut corners when coding software. The greater the pressure to deliver software, the greater incentive to cut corners. The more corners cut in the past, the harder it is to deliver new software value in the future.
Technical debt imposes significant business costs. In an era of digital transformation, organizations respond more slowly to threats and opportunities. What little trust might exist between business users and IT diminishes, as estimates become longer and less reliable. The morale within the software development organization drops.
Technical debt isn’t intrinsically bad. As the person who coined the term, Ward Cunningham, argued, there are plenty of situations in which it makes good business sense to cut a corner to seize an important market opportunity, or perform a critical experiment. However, the problem isn’t a single hack here or there, but the crushing weight of many, many such hacks and other shortcuts over time.
Both technologists and their customers might see a common interest in addressing technical debt. Unfortunately, more often than not, they don’t. Even the executives leading the software development and delivery efforts don’t always understand the scope of the technical debt problem, or the cost of not fixing it.
Therefore, there are many dimensions to technical debt. The wellspring of technical debt is the most technical, starting with basic software development practices. There are other dimensions, too, involving the social sciences as much as computer sciences. Organizational dynamics and software economics have as much to do with technical debt as the impact of copying and pasting code sections.
An upcoming issue of Cutter IT Journal with Guest Editor Tom Grant hopes to cover these multiple dimensions of technical debt. Therefore, we are looking for contributions from some of the usual suspects, people who know how to assess and “pay off” technical debt within software development. We are also looking for people who know how to deal with technical debt outside the IDE and testing tools — for example, by helping business users see their contribution to the creation of technical debt.
Possible discussion points include those mentioned above, as well as, but not limited, to the following:
- What are the most important significant sources of technical debt?
- What are the other software innovation problems that are distinct from technical debt, but related to it?
- Why do teams struggle to deal with technical debt?
- How do you get teams to prioritize the ongoing effort to reduce and prevent technical debt?
- What types of teams or organizations have had the most success dealing with technical debt? For example, are Agile teams in a stronger position to address technical debt?
- What are the best ways to use tools to address technical debt?
- How do you help IT executives understand the importance of dealing with technical debt?
- How do you assess the impact of technical debt on the business?
- How do you get the business to see its role in the technical debt problem?
- Since you cannot eliminate all technical debt, what is an acceptable level?
ARTICLE IDEAS DUE: JANUARY 27, 2016
Please respond to Tom Grant at tgrant[at]cutter[dot]com, with a copy to cgenerali[at]cutter[dot]com no later than January 27, 2016 and include an extended abstract and a short article outline showing major discussion points.
Accepted articles are due by February 26, 2016.