Growing up the youngest child meant that my closest brother (6 years my elder) would terrorize 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 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 hear to terrorize you with technical debt.  Lets start making technical debt something a 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.  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 a team.

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 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 these code quality tools 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 leveraging 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.