ITMPI FLAT 003
Main Menu
Home / Project Management / Risk Management / Clean Up Technical Debt to Clean Up Risk

Clean Up Technical Debt to Clean Up Risk

Chris Matts likens programming to a kitchen. When the kitchen is dirty and utensils are in strange places, the chef has to do a lot of cleaning and rearranging before he can start cooking. Likewise, sloppy, repetitive code becomes technical debt that must be cleaned before good new work can begin. When you fail to clean, you could slip and break your neck.

More Cleaning, Less Neck Braces

Matts talks about a former colleague of his, Steve Freeman, who “is the Gordon Ramsay of Software Development.” Freeman will tell you exactly how bad your code is, and he can back up his assertions. Matts says Freeman once reduced the size of a codebase by 80 percent. You should not be relying on someone like this to clean up your mess.

Better code begins by defining what good code looks like in the first place. Three forms of risk emerge when you do not address technical debt: delivery risk, business case risk, and risk to the existing model. Delivery risk involves big problems creeping up during the test phase, where it is too late to manage technical debt. Include more regression testing to account for this. Business case risk emerges from software not delivering the expected value as a result of impediments from technical debt. And risk to the existing model has to do with the fact that technical debt can increase likelihood of critical failure in production.

When you want to pay down the debt before it causes problems, consider this method:

For each component of the system, the team can identify how much technical debt exists. The measure for the technical debt should be how much effort it will take to pay it down. This effort should consider how complex the debt is, and the staff liquidity matrix, namely how many team members can work on the component.

The product owner can then create a “tornado map” where they map out the high level road map for the next six months to a year. The further out, the more uncertainty there is. Using the tornado map, the product owner and team can work out which technical debt should be paid down now and which can be left.

The biggest part of stopping technical debt is developing a mindset that will not allow you to settle for fast and sloppy, not even in just the short-term. You can read Matts’ original post here: https://theitriskmanager.wordpress.com/2014/12/31/technical-debt-is-risk-management/

About John Friscia

John Friscia is the Editor of Computer Aid's Accelerating IT Success. He began working for Computer Aid, Inc. in 2013 and continues to provide graphic design support for AITS. He graduated summa cum laude from Shippensburg University with a B.A. in English.

Check Also

Do You Avoid These Common Project Management Mistakes?

You only know you’ve mismanaged a project once something has broken. These slip-ups can result …

Leave a Reply

Your email address will not be published. Required fields are marked *