The Pragmatic Management of Technical Debt

Software is a little like those expensive shiny new electronics that we all crave. We spend a bunch of money acquiring one. It’s great. Solves all of the problems that we had. Runs fast. Looks outstanding. Then the ravages of time overtake it. It starts getting grimy. Scratched. Dented. We spend more money keeping it shiny and cool looking. But eventually, it gets too slow to run the latest problem-solving stuff, and we start to think of the next expensive shiny new electronic thing to replace it. But now, we’re talking real money, and we hesitate. Should we just keep our old, slow (and getting grimier by the day) device, or spend money (that perhaps we don’t have, and will have to borrow) to acquire a new one? Such is modern life. And such is the life of software. This session is not about the newest shiny devices, but about the software that we write day to day. In the quest to keep software being developed on a schedule that is acceptable to the business, as we add new features and functionality, we sometimes cut corners, instead of doing the refactorings that the software should have day-to-day. Sometimes, we’re even forced to “hack” a solution together because “working software” is our highest priority. But no one said that working software is written in a way that we’d be proud to show our friends! And if we continue to work that way, one day the product owner will find that our estimate for completion, whether explicit or derived from metrics such as story points or cycle time, are simply too high for the benefit expected. Then what? In this session, Howard will look into such perennial questions as “should short-term technical debt estimates be included in story points”, “how should we deal with long-term technical debt?”, and “should technical debt have its own backlog?” We will talk tools and techniques related to finding where technical debt is hiding. And we will do all of this with a mindset that isn’t dogmatic with either “all technical debt is bad” nor “the future will take care of itself”.Read less