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

Prioritizing Technical Debt

Prioritizing Technical Debt

Michael Cheng

July 03, 2020
Tweet

More Decks by Michael Cheng

Other Decks in Programming

Transcript

  1. Prioritizing Technical Debt
    Taming the beast!

    View full-size slide

  2. What is technical debt?
    Tech Debt 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.
    - "We took a shortcut"
    - "This is a hack"
    - "We'll fix that later"

    View full-size slide

  3. ● Reckless & accidental
    ● Reckless & deliberate
    ● Prudent & deliberate
    ● Prudent & accidental
    (unintentional)
    Source: https://softwarebrothers.co/blog/technical-debt-what-it-means-and-how-to-deal-with-it/
    Types of technical debt

    View full-size slide

  4. Paying off the technical debt
    ● Like any kinds of debt, you eventually need to pay it off.
    ● When is the moment to start paying tech debt?
    ○ When the cost of change is too high:
    ■ "It takes 3 weeks to implement a button".
    ○ Brittle code: Too many moving parts, change one line
    and everything fails.
    ○ You need more effort to understand the code.

    View full-size slide

  5. Stop the leak
    Step 1

    View full-size slide

  6. Stop the leak
    ● Be deliberate in your code design.
    ● Refactor your code as soon as it works.
    ○ TDD Cycle: Red, Green, Refactor
    ○ Tests gives you more confidence in refactoring your
    code
    ● DRY is not always a good thing
    ○ Wrong layer of abstraction
    ○ Premature optimization

    View full-size slide

  7. Stop the leak
    ● Recognize code smells
    ● https://refactoring.guru/refactoring/smells

    View full-size slide

  8. Tech Debt Sprints
    Step 2

    View full-size slide

  9. Tech Debt Sprints
    ● Run a Tech Debt Workshop
    a. Get everyone to identify tech debt in the code and put
    them on 1 post-it note each.
    b. Put them all on the board. Identify clusters.
    c. Organize them into value & complexity/effort quadrants.
    ● Plan and do the tech debt recovery.

    View full-size slide

  10. Examples
    ● Documentation for a shared library.
    ● Removing dead code from a feature
    toggle.
    ● Audit on Open Source licenses used.
    ● Upgrade to the latest version of Preact.
    ● Remove use of IE7 Shims.
    ● Decouple library A from B.
    ● Refactor Payment module.
    ● Extract out a repeated method into a
    shared library.
    ● Use dependency injection instead of
    initializing a new instance everywhere.
    ● Performance tuning for API requests.
    ● Reduce memory footprint of all app
    servers.
    ● Standardize the use of Webpack config
    across all microservices.
    ● Enhance stability of build pipeline.
    ● Reduce load time of web front-end by 2
    seconds.
    Where would you put these stories on the Value vs Complexity/Effort quadrant?

    View full-size slide

  11. Continuous Pay Down
    Step 3

    View full-size slide

  12. Continuous Pay Down
    ● Include tech debt repayment stories in every sprint.
    ○ Example: "10% of stories in this sprint backlog should be
    tech debt stories."
    ○ Pull from the tech debt sprint board.

    View full-size slide

  13. Continuous Pay Down
    ● Opportunistic refactoring - as you are working on a story
    spend some time to refactor.
    ○ Do it after you are done with the "acceptance criteria".
    ○ Beware the rabbit hole.

    View full-size slide

  14. Continuous Pay Down
    ● Revisit the tech debt board once in a while.
    ○ Revise with another workshop.

    View full-size slide

  15. Continuous Pay Down
    ● Add test coverage of legacy code before you refactor.
    ● Document the coding conventions, styles and design
    patterns that are "good practices".
    ○ Help new joiners to understand why certain things are
    good and bad.
    ○ Architecture Decision Record
    (https://github.com/joelparkerhenderson/architecture_decision_record)

    View full-size slide

  16. Continuous Pay Down
    ● Resist the urge to restructure until you know enough
    about the current & future use cases.
    ○ "Duplication is far cheaper than the wrong abstraction"
    ○ "Prefer duplication over the wrong abstraction"
    ■ Sandi Metz
    (https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction)

    View full-size slide

  17. Conclusion
    ● Tech debt can be managed but never quite paid off
    completely.
    ○ New code can accidentally introduce tech debt.
    ● Tech debt can be a matter of opinion too.
    ○ Some repetition results in less indirection and more
    readable code.
    ● To pay or not to pay - you have to decide as a team.

    View full-size slide

  18. Questions?
    @CoderKungfu (Instagram & Twitter)

    View full-size slide

  19. About Me
    ● 1998-2002 - Majored in History & Political Science in NUS
    ● 2004 - Started my own web design company (eNeighbourhoodStore)
    ● 2006 - Sold it to a digital agency (Comwerks)
    Founded Singapore PHP User Group
    ● 2011 - Joined my first startup: Foound
    ● 2012 - Co-founded iOS Dev Scout
    ● 2013 - Started Engineers.SG
    ● 2012-2019 - Software engineer (migme, Neo Innovation,
    Pivotal Labs, SP Digital (SPGroup))
    ● 2018 - Started JuniorDevSG
    ● June 2019 - Joined GovTech Singapore

    View full-size slide

  20. Michael Cheng
    @CoderKungfu
    (Twitter & Instagram)

    View full-size slide