Neil Ernst - Technical Debt in Practice : How to Find It and Fix It

1. List of Figures
2. Technical debt quadrants.
3. Fishbone diagram of the causes of technical debt, per software lifecycle phase. A fishbone (or Ishikawa) diagram represents a problem on the right (head) and causes of that problem on the left.
4. Technical debt and the software value curve.
5. A value stream model, with sample tools. The arrows show how the idea moves from an issue tracker all the way to an A/B test result. This visualization can highlight bottlenecks, where a feature takes the most time to progress.
6. A DSM of an industrial project showing structural dependencies.
7. A DSM of the project in figure 4.1, now showing evolutionary dependencies.
8. Design complexity and design flaws in the real world.
9. Source: left image: https://pxhere.com/en/photo/996703 ; right image: Rick Kazman.
10. Example of a cyclic dependency.
11. Architecture antipatterns in Apache Hadoop.
12. Data collection and analysis for the SS1 project.
13. Debt calculation for the SS1 project.
14. Architecture debt calculation.
15. Good commit messages explain the change and include other details.
16. Bad commit messages dont explain the change.
17. Dashboard from code-inspector showing trends in a codebase. (a) Metrics and trends; (b) categorized violations; (c) duplicated code.
18. Example dashboard offered by coveralls.io: coverage metrics are showing which files have appropriate levels of testing and which files require more testing.
19. Example of metrics trends (CPU and Memory utilization) over a day.
20. Winston Churchill giving the V (for Victory) sign in 1943.
21. The machine learning ecosystem. Note the small size of the machine learning codethe modelrelative to the entire system.
22. Exponential growth in communication networks.
23. Technical debt and the software value curve.
24. List of Tables
25. Industrial benchmark data. Higher DL and lower PC are better.
26. Architectural measures for the platform with and without co-change information.
27. Architecture root analysis
28. Design flaws in Brightsquids platform
29. Architecture flaws in the platform before and after refactoring
30. Productivity measures for Brightsquids platform
31. Project context and documentation approaches
32. Approaches to documentation
33. Community smells (adapted from [Tamburri 2016] and [Tamburri 2019])
34. Community smell mitigations
35. List of Boxes
36. Financial Literacy Test
37. Voice of the Practitioner: Andriy Shapochka
38. Types of Requirements
39. Requirements Traceability in Chromium
40. Lean and Agile and Requirements Debt
41. Coupling and Cohesion: A Primer
42. Design Principles
43. Finding Security Design Flaws in Chromium
44. Software Metrics and Lines of Code
45. Voice of the Practitioner: Marco Bartolini
46. To Use or Not to Use a Security Framework
47. Code and Bug Duplication
48. Voice of the Practitioner: Nicolas Devillard
49. Voice of the Practitioner: Andriy Shapochka
50. Voice of the Practitioner: Marco Bartolini
51. Voice of the Practitioner: Julien Danjou
52. Cost Estimation and Technical Debt
53. Voice of the Practitioner: Andriy Shapochka

This book would not have happened without the help and inspiration of a lot of different people. The three of us met while working at the Carnegie Mellon University Software Engineering Institute in Pittsburgh. Thanks to all our coworkers at the SEI, including Robert Nord, Peter Feiler, Ipek Ozkaya, James Ivers, Felix Bachmann, John Klein, Stephanie Bellomo, Phil Bianco, and Chuck Weinstock. Linda Northrop remains an inspiration.

Rick Kazman would especially like to thank his research collaborators, including Yuanfang Cai, Damian Tamburri, Humberto Cervantes, and the group at SoftServe, including Serge Haziyev and Andriy Shapochka.

Julien would like to thank Julien Danjou and Nicolas Devillard for their time.

Neil would like to thank his collaborators, as well as the anonymous reviewers of this manuscript, who although causing more late nights, doubtless improved the final version.