Evaluating when it’s time to tackle technical debt

Working on technical debt is a necessary part of every engineering teams’ business as usual priority list; but how do you balance work on features and technical debt work? Investing too heavily in feature work could lead to cumbersome systems with potentially cascading failures, and investing too heavily in technical debt work can lead to features necessitated by the customer being left unmade and can effect the sense of progression, and morale, within your teams.
In this panel, we’ll be taking a look at how to decide when to work on technical debt and when to stop. We’ll be thinking about how to plan ahead, how to prioritise tech debt work and watch for warning signs of larger problems, and discuss how to convey this work to your teams.

[@johnbeech]

"The work you gotta do tomorrow because you took a shortcut in order to deliver something today." - brilliant way to put it - I'm starting to talk my colleagues out of using "technical debt" as a catch all for those shortcuts and instead talk about long term value of product and service features - Resiliency, Scalability, Responsiveness, Redundancy, Improved Cycle Time, Reduced Lead Time, Simplicity (reduced cognitive load), Improved Accessibility, Improved Confidence, Reduction in Manual Testing, and so on. Not having good hygiene factors in place - standards for READMEs, Pull Requests, Test Strategy, not sweeping up after yourself, "always trying to bake, but never tidying up".
Anyhow, great chat; thanks everyone on the panel for bringing out the conversation.

[@frontendbrasil]

Great discussion! ❤️