An enterprise perspective on technical debt

Situated Boundary Spanning

“…Allman argues that understanding, communicating, and managing technical debt is essential for the long-term success of a system. Whereas technical debt was initially conceptualized as producing immature code in order to deliver solutions to market needs [Cunningham 1992], a broader view includes the notion of tradeoffs between short-term decisions made during development and their potentially long-term costs [Klinger et al 2011]. Thus, whereas both conventional and agile development approaches may accumulate technical debt, the issue is more pronounced and observed relatively more quickly in agile development due to its focus on time-to-market considerations.…”

How Bad is it? – A Branching Activity Model to Estimate the Impact of Information Security Breaches

“…It is vital that people and organizations recognize and learn from near-miss events. Another example is captured in the phrase 'technical debt' (Brown et al 2010, Guo et al 2011, Klinger et al 2011, which refers to short cuts and other expedient actions taken by IT system designers prior to a release. These may not 'cost' them anything in the very short-run, but sooner or later the 'debt' must be paid off eventually, either through patching or through the cost of security breaches.…”

Large-Scale Automated Refactoring Using ClangMR

“…Large software systems often suffer from an inability to evolve to meet new demands [1], largely due to increasing amounts of technical debt [2], and the inability of code maintainers to automatically update large portions code in a semantically safe way. Even automatic changes which may appear safe in isolation may introduce semantic conflicts that cause faults which are difficult to detect [3].…”