Devs Always Pay their Debts

Programmers always pay their debts

Debt. Debt never ends. But it is not always the tools; it is the people who wield them that win the battles. In software engineering, we are constantly waging war against technical debt. Many of the projects we believe in fail precisely because they lose that war.

In this talk, we will try to identify the enemy, familiarize ourselves with the weapons we have to combat it, and propose some strategies to win the battle against the infamous "legacy code."

Through intelligence, we will learn tactics to identify, tackle, and reduce technical debt, and emerge victorious in our software projects.

Transcript

1. DEVS ALWAYS PAYS THEIR DEBTS
3. WHY?
4. MEIR M. LEHMAN LÁSZLÓ BÉLÁDY LEHMAN LAWS OF SOFTWARE EVOLUTION Head of Computer Department at Imperial College of London Hungarian Computer Scientist
5. Program, life cycles & laws of software evolution (1974) “A system must be continually adapted or it becomes progressively less satisfactory.”
6. Program, life cycles & laws of software evolution (1974) “As the system evolves, its complexity increases unless work is done to maintain it.”
7. Program, life cycles & laws of software evolution (1974) “The quality of a system will appear to be declining unless is rigorously adapted to operational environment changes.”
8. THE DILEMMA Over time, our software will evolve, becoming more complex, and unless we take an active role to maintain it, its quality will decrease
9. Ward Cunningham talking about a ~1992 Smalltalk project “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, object-oriented or otherwise.”
10. TECHNICAL DEBT
11. Martin Fowler talking about technical debt (2019) “Software systems are prone to the build up of cruft - deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further.”
12. COMPLEXITY
13. PROBLEM COMPLEXITY SOFTWARE COMPLEXITY
18. HOW DO WE PERCEIVE COMPLEXITY? BUSINESS • Longer cycle times • Unpredictability • Organizational issues • Low Innovation ENGINEERING • Developer attrition • Key personnel dependencies • Attentional capacity limitation CUSTOMERS • Crashes • Slowness • Unexpected flows
19. COMPLEXITY = TIME
20. TIME = MONEY
21. COMPOUND INTEREST FORMULA A=P(1+n/r )nt
22. DEFAULTERS VS CLEANERS • Does not address complexity • Development increases +25% each iteration • Regularly addresses complexity • Uses additional ½ days to reduce complexity 20% DEFAULTERS CLEANERS
24. SHOWDOWN RESULTS DEFAULTERS 33.4 DAYS 16.2 DAYS CLEANERS
25. Cleaners delivered the same work in half the time
26. Cleaners could have shipped twice the features in the same time
27. Paraphrasing Agent Smith in Matrix Complexity is a plague, and we are the cure.
28. PLAGUE VECTOR MICE Gets infected by eating food or water contaminated by the parasite CAT Ingests mice and the parasite reproduces on his digestive tracts FECES Toxoplasma oocysts get excreted SOIL Gets contaminated by long living oocysts
29. COMPLEXITY VECTOR Storage UI Sensors Network Presenters Use Cases Stores Repositories Entities
30. COMPLEXITY VECTOR Storage UI Sensors Network Presenters Use Cases Stores Repositories Entities BOUNDARY LAYER MAPPERS
31. STATIC ANALYZER * Project with technical debt ratios < 5% are marked as A 2 YEARS A* First commit on Jan 24, 2019 (~5,5 years ago) 24,289 Files 1,795 Code smells 1,415 Duplications
32. ATENCIÓN, CHISTACO
33. GIT
38. Change Frequency Complexity Hotspot!
39. Hotspot!
40. TAKEAWAYS Tools provide remediation time, not the cost If you are improving the code, you’re not shipping features Complexity lies dormant until faced HIDDEN COST TRADEOFF INVISIBLE
41. BROKEN WINDOWS THEORY
42. Our job as developers is to own the code. Not making the code more complex, but actively try to simplify it.
43. Relative cost to fix complexity, based on time of detection Requirements Coding Integration Acceptance Production 5x 10x 15x 20x 25x 30x Source: NIST
44. REDUCING COMPLEXITY Less complexity on the lower level: Single responsibility elements, small pieces of code… Less complexity on the high level: systems communicate via contracts, not leaking implementation details… HIGH COHESION LOOSE COUPLING
45. EARLY WARNING SYSTEMS 1 2 3 IDE-INTEGRATED STATIC ANALYSIS TOOLCHAIN BASED LINTING PROJECT-LEVEL HEALTH TOOLING
47. REFACTORING
48. “Refactoring is the process of restructuring computer code without changing its external behavior.”
49. DATA STRUCTURES REFACTORING REGEX MODELLING ARCHITECTURES TESTING PATTERNS
50. TEST IS KING
56. HOW TO APPROACH A REFACTOR ENSURE CODE IS TESTABLE OR HAS TESTS FIRST UNDERSTAND WHAT IS THE COMPONENT ROLE RAISE COHESION
57. ORGANIC DESIGN Focused service that handles a specific task Microservice that operates independently Group of services that form a larger domain ORGANELLE CELL ORGAN
58. • Complexity influences all aspect of software development • Domain complexity can rarely be removed, and there is an inherent one in software engineering • Proactive elimination of such complexity should be a part of the development process, and its early detection is critical WRAPPING UP
59. CREDITS: This presentation template was created by Slidesgo, including icons by Flaticon, infographics & images by Freepik THANKS Do you have any questions? sefford@gmail.com @sefford