Slide 1

Slide 1 text

Prioritizing Technical Debt Taming the beast!

Slide 2

Slide 2 text

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"

Slide 3

Slide 3 text

● 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

Slide 4

Slide 4 text

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.

Slide 5

Slide 5 text

Stop the leak Step 1

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Tech Debt Sprints Step 2

Slide 10

Slide 10 text

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.

Slide 11

Slide 11 text

1 2 3 4 4

Slide 12

Slide 12 text

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?

Slide 13

Slide 13 text

Continuous Pay Down Step 3

Slide 14

Slide 14 text

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.

Slide 15

Slide 15 text

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.

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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)

Slide 18

Slide 18 text

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)

Slide 19

Slide 19 text

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.

Slide 20

Slide 20 text

Questions? @CoderKungfu (Instagram & Twitter)

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Michael Cheng @CoderKungfu (Twitter & Instagram)