Technical Debt and the Boogie Monster

Growing up as the youngest child meant that my closest brother (6 years my  elder) terrorized me with threats of the boogie man coming to get  me.  It was a rather effective tactic – how to deal with the boogie man  wasn’t well known, and the internet was just a glimmer in Al Gore’s eye.   I see and have been part of a similar tactic in agile software development.  I  have terrorized product owners and business sponsors with the concept  of technical debt.

‘Ooh, that change is going to take a long time. That code that  so-and-so wrote 3 years ago is real bad.’

‘Well, yeah, we could do it that way, but it will fall apart.’

‘The code is so bad we just need to start over and re-architect it.’

These three sample comments stem from the same situation – ugly,  nasty, boogie man type code.  Fear not, I am not here to terrorize you  with technical debt.  Let’s start making technical debt something the whole team can use and discuss in a productive manner.

First off, what is technical debt? Simply put, technical debt is  software that has been implemented in such a way that future progress is  hindered.  Have you seen a project where a seemingly simple change or  bug defect took weeks and introduced other problems along the way?  You  saw technical debt in action. The decisions and shortcuts in system  implementation that cause technical debt are usually made due to time  constraints, but can also come from sheer laziness.  There are tons of  articles on technical debt – I would recommend reading either this  posting by Martin Fowler or this one by Uncle Bob Martin.

As Martin and Uncle Bob point out, technical debt isn’t always bad for software product development.   If time is critical for a competitive advantage, we may want our product  out as soon as possible.  Or we may be breaking new ground and need a  prototype to see if a concept is achievable / if there is a market for  an idea.  Both are logical reasons for taking initial shortcuts, as long  as we go back and work on paying down that technical debt.  How can we  start creating meaningful discussions around technical debt?  The same  way you take care of the boogie man – you shine light on it.

I come from a Java background and am a big fan of the open source  project Sonar.  Sonar  is a code quality management tool, leveraging other open source code  analytic packages.  It provides time sequencing of code quality as well –  so we can see if our code is getting better or worse, and at what  rate.  It also provides nice views into high risk areas as well as areas  that can be quick wins for agile teams.

Can people get lost in the details of Sonar? Most definitely.  But at  the very least, I hope this levels the playing field between the team  creating the software and the person / group requesting the software.   Here is how Sonar (or any consolidated code quality tool) can be highly  beneficial for a team and an organization delivering software:

Provide understandable visibility into code quality

Even without explaining how complexity is measured to non-technical  people, it is easy for anyone to grasp certain things – this software development project has  a lot of red while these others are green.  This project says there are  lots of violations and there is a lot of risk. That can’t be good.  Use  these tools to level the playing field and start discussions.

In Sonar, we create code profiles.  We suppress violations that don’t  make sense to our organization, prioritize our code style, and set up  visual flags around other metrics such as complexity and test coverage.   As someone paying for software, I want to know it is being created with  care and of high quality.  As a developer, I want to promote my  attention to detail and also want means to help me explain why I need  some additional time to keep the cost of future maintenance low.  These  metrics allow us to talk to the numbers.

Assist teams dealing with legacy code

Legacy code is here and it isn’t going anywhere.  An easy cop out to  not write unit tests is, ‘it’s old code and it doesn’t have  any tests.’ The logic being that since the code doesn’t have any tests,  it would be so terribly difficult to get any tests written.  Leverage  these code quality tools to show you where there is a high risk area and  target your tests there.  Its like having a big ball of tangled yarn –  let the tool give you one end and a big loop to help you start  untangling it.

Provide context and depth to the cost of change and feature adds

Use code quality tools throughout the software development process to help provide more context to why a  new feature is going to take as long as estimated.  When we are in our  planning sessions, reference Sonar and explain why a story or feature  request has a high estimate.  Similarly, we can compare to an easier  change and see there is less risk.

Create a plan for addressing fragile code

Don’t take a hack and slash approach to lowering your technical debt.  All that will happen is all of the ‘easy’ changes will get done and  none of the real valuable changes will be addressed.  Instead, use a  surgical precision approach by using Sonar and similar tools to  come up with a  plan for addressing the weaknesses of the code by  targeting areas and see the progress  visually.

Like most quality tools, Sonar is not the decision maker; it is  the conversation starter.

Interested?

Read more by Joel Tosi @ http://communalosmosis.com

This entry was posted in Agile Development. Bookmark the permalink.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>