Purging the Technical Debt - From Concept to Implementation

This is the deck I prepared for a webinar I had the chance to share with JetBrains on the subject of technical debt. You can watch the webinar here: https://www.youtube.com/watch?v=_qMeJQ9Rzso&t=2s

The main theme about the presentation is to understand what technical debt is, how it affects team productivity and product quality, as well as a few tools available that can help us to purge it.

Transcript

1. Purging The Technical Debt Brian Di Croce, B.Eng., MCPD @bdicroce
2. Context Side Effects Tools and Technologies Processes Wrap Up
3. Let’s start
5. What is a technical debt?
6. https://en.wikipedia.org/wiki/Technical_debt “Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.” - Wikipedia
7. What is the consequence if we don’t deal with it now?
8. The term “technical debt” was coined by Ward Cunningham (co-creator of XP) almost 30 years ago. "Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid. Every minute spent on “not-quite- right” code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation."
11. LATER? NOW?
13. Why should we not ignore our technical debt?
15. Because it gives us a sense of pride
17. Because we care about the things we value
19. Because we’re in it for the long run
21. In 2018, Stripe published the results on an interesting study related to the current state of software development The Developer Coefficient: Software engineering efficiency and its $3 trillion impact on global GDP (PDF)
22. COMPANIES WASTE $300 BILLION OF DEVELOPER PRODUCTIVITY EVERY YEAR “Developers spend over 17 hours every week dealing with maintenance issues like debugging and refactoring, and about a quarter of that time is spent fixing bad code. That’s nearly $300B in lost productivity every year. It’s not how many software engineers a company has; it’s how their talent is being utilized.” Source: The Developer Coefficient: Software engineering efficiency and its $3 trillion impact on global GDP
23. Source: The Developer Coefficient: Software engineering efficiency and its $3 trillion impact on global GDP
24. What causes technical debt?
25. complexity
26. The law of software entropy states that as a system is modified, its disorder (entropy) tends to increase
27. In software development, that disorder (entropy) is represented by the delta of complexity
28. In his book The Mythical Man-Month: Essays in Software Engineering(1975), Prof. Frederick P. Brooks distinguishes two types of complexity: Essential Complexity Accidental Complexity
29. Essential complexity is the fundamental implementation of functionalities to make the system work according to its intended purpose regardless of the inherent complexity
31. Accidental complexity is the non-essential code or quick fixes that are implemented to prove a temporary idea or get a short-term gain, but remains intrinsic in the system.
33. Accidental complexity is the main contributor to the technical debt.
34. But it’s not the only one…
35. Unrealistic project constraints
37. Poor understanding of the problem
38. Lack of a comprehensive suite of tests
39. Immature design or system architecture (high coupling and low cohesion)
40. An incomplete or weak CI/CD strategy
41. Inefficient tools and processes
42. Software entropy increases in direct proportion to the technical debt
43. The Side Effects of Technical Debt
44. Business logic intertwined all over the codebase
45. Hundreds or thousands lines of code within a method or stored procedure
46. Continuous deployments solely to fix bugs in production
47. Security vulnerabilities exposed publicly
48. Unit tests that randomly pass or fail depending whether they’re executed individually or in parallel
49. Tools and Technologies SonarQube JetBrains Rider/ReSharper NDepend (.NET) StepSize (VSCode ext.)
50. SonarQube
51. JetBrains Rider/ReSharper (IntelliJ for Java folks)
52. NDepend (.NET)
53. StepSize (VSCode extension)
54. Processes
55. Look into the practices of Extreme Programming
56. Rapid Feedback Pair programming Planning game Whole team
57. Continuous Process Continuous integration Refactoring Small releases
58. Shared Understanding Coding standards Collective code ownership Simple design System metaphor
59. Programmer welfare Sustainable pace
60. Look into the values of Extreme Programming…
61. Communication
62. Simplicity
63. Feedback
64. Courage
65. Respect
66. Wrapping Up
67. Remember that you don’t have to ask permission to do the right thing
68. Thank you