Permission to Tackle Tech Debt

I recently read this blog about Tech Debt and really liked the authors point.  To paraphrase, "Bad code isn't tech debt it's more like an all-or-nothing bet with a hard payout date."

While debt can be slowly paid down and may carry with it some upside like tax deductions, bad code does not.  It usually has a near term payoff and a long term bleed.  Once the benefit has been realized, it's rarely cleaned up.  New code has to straddle old, messy code and thereby become messy and suboptimal itself.  Subsequent growth now faces the same challenge to a greater extent. The growth is exponential in nature, not linear.

Like a tree that grows around an obstacle, it follows the path of least resistance, getting the job done but eventually sacrificing its structural integrity.  Things progress status quo until something catastrophic happens causing people to take notice.

Convincing the business to pay for the cleanup is difficult and usually the level of effort is underestimated.

In short, the debt metaphor doesn't clearly communicate the sense of urgency that should accompany the need to cleanup messy code.  This phenomenon has hamstrung entire industries, a recent example being the regulatory yoke placed on Wall St post 2008 "Lehman Shock."

So what can you do?  Below are some proven steps based on experience:

• Communicate the risks to the business.  To the extent possible make this quantifiable and objective
• There's a 30% risk in the next year that we'll have a 1d+ duration outage of system X. 
• This system costs the business $10k/h of outage.
• That means 30% * 24h * $10k = $7.2k or more risk per year
• The estimated cleanup cost is 40man hours @ $250/hr = $10k.
• Break even ~1.5 years.
• Negotiate
• Suggest an allocation of x% of engineering time per sprint dedicated to tech debt stories.
• Point out that downtime naturally exists and the cleanup cost is not entirely incremental.
• Create a tech debt backlog
• Populate it with some stories
• These will serve as examples for others so be careful and intentional about the content and format.
• Socialize the risk of tech debt within the engineering team.
• Use this conversation as a mentoring opportunity between team members to introduce more junior members to architectural topics.
• Empower individual engineers to create their own stories and add them to the backlog as they encounter problems.
• Allocate some time after each sprint to prioritize the stories based on objective criteria like risk to the business.
• At the start of each sprint, pull in stories to satisfy your contractual percentage time.  If there are none, focus on features.
• Measure your progress and report to the business periodically.  After all they're paying on blind faith and trying to run a profitable business.  They need evidence that their money is not being wasted.

In my home whenever I see a mess I tell my family, "You all have my permission to clean this up."  After repeating myself a few times with no action I joke, "Wow look at all the permission in here!"  These days, "permission" has taken on a whole new meaning in my home.  Don't get bogged down by "permission."