Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Devs Always Pay their Debts

Saúl Díaz
September 27, 2024

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.

Saúl Díaz

September 27, 2024
Tweet

More Decks by Saúl Díaz

Other Decks in Technology

Transcript

  1. 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
  2. Program, life cycles & laws of software evolution (1974) “A

    system must be continually adapted or it becomes progressively less satisfactory.”
  3. Program, life cycles & laws of software evolution (1974) “As

    the system evolves, its complexity increases unless work is done to maintain it.”
  4. 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.”
  5. 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
  6. 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.”
  7. 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.”
  8. 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
  9. DEFAULTERS VS CLEANERS • Does not address complexity • Development

    increases +25% each iteration • Regularly addresses complexity • Uses additional ½ days to reduce complexity 20% DEFAULTERS CLEANERS
  10. 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
  11. 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
  12. GIT

  13. 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
  14. Our job as developers is to own the code. Not

    making the code more complex, but actively try to simplify it.
  15. Relative cost to fix complexity, based on time of detection

    Requirements Coding Integration Acceptance Production 5x 10x 15x 20x 25x 30x Source: NIST
  16. 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
  17. HOW TO APPROACH A REFACTOR ENSURE CODE IS TESTABLE OR

    HAS TESTS FIRST UNDERSTAND WHAT IS THE COMPONENT ROLE RAISE COHESION
  18. ORGANIC DESIGN Focused service that handles a specific task Microservice

    that operates independently Group of services that form a larger domain ORGANELLE CELL ORGAN
  19. • 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
  20. CREDITS: This presentation template was created by Slidesgo, including icons

    by Flaticon, infographics & images by Freepik THANKS Do you have any questions? [email protected] @sefford