Agile · Communication · Decision making · Development velocity · New features · Planning · Principles · Product management

Technical debt

The topic of technical debt came up in a couple of settings this week at work.  I’ve written about this topic before here (among other places) but two different situations raised this issue in the past week and a third provoked an interesting set of questions.

First was a response from one of my readers.  He noted an unfortunate tendency even in Agile development shops to focus on new projects and features while allowing existing products that work ‘well enough’ to accumulate technical debt that the client support team has to work around.  In spite of the Agile principle emphasizing, “Continuous attention to technical excellence,” there is generally more excitement in developing something new and cool than there is for refactoring existing code and decreasing technical debt.  In their strategic and tactical thinking, the product manager and product owner have to remember the importance of maintaining a clean and easily supported codebase, even if doing so decreases development velocity in the short-term.

The second context in which technical debt came up this week was my continued reading of The Art of Agile Development by James Shore and Shane Warden.  In discussing XP adoption for existing codebases, they make the following assertion:

The biggest challenge [in starting to use XP on a legacy project] is setting aside enough time to pay down technical debt.  If you have a typical legacy project, your current velocity is a polite fiction based on shortcuts… You incur new technical debt in order to meet your deadlines.  To improve productivity and reduce bug production… you need to set aside extra slack for paying down the existing debt.

I have seen firsthand on projects in the past couple of years the palpable difference it makes when development teams prioritize both writing clean code and refactoring existing code to diminish existing technical debt.  The payoffs that come in the form of easier client support, faster issue analysis, and more confident new coding all make a commitment to regular refactoring well worth the investment of time and effort.

Which brings me to the third and most provocative context in which technical debt surfaced this week.  In talking about important prerequisites for a company wanting to move to XP, the authors of The Art of Agile Development call for “compensation and review practices that are compatible with” this programming approach.  A group of people in my firm who are reading this book together raised the question of what it really looks like to provide proper incentives for pursuing the XP practices.  Are people rewarded for taking extra time to write cleaner code and for refactoring code in other parts of the system because it makes everyone’s life easier?  How do you balance encouraging development teams to focus on the critical path to building a minimum viable product with the value of wider refactoring in the broader codebase to benefit the entire product suite?  When a specific business team is watching its development spend is it ok for the coders to clean up related functionality or should they leave those issues for some future team to (hopefully one day) address while narrowly focusing only on their own product code?  How much – if any – slack is acceptable to leave in a sprint plan when a team wants to get a marketable product delivered to prospective clients before a competitor can develop it?  We batted these questions around a bit – at both a theoretical and a practical level – but couldn’t settle on any clear solution because in truth it’s not that simple.

What do you think?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s