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"
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.
• 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
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.
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?
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)
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)
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.
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