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"
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.
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
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.
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?
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.
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.
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)
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)
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.
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
miccheng
pangmoo
manfredsteyer
maguroalternative
os1ma
munetoshi
ayaka1230
mukky620
takefumiyoshii
ancaghenade
shioyama
fendo181
eileencodes
addyosmani
bryan
morganepeng
edds
3n
holman
dougneiner
afnizarnur
schacon
ddemaree
davidbonilla