Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

Pollution as a metaphor to explain Technical Debt metaphor

During the recent Agile Coach Camp, during one of the discussions, Chet Hendrickson talked about using Pollution as a metaphor to better explain Technical Debt. Following is my interpretation of what he proposed.

Martin Fowler explains Technical Debt as the following:

Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about the problem where the architecture of a large software system is designed and developed too hastily. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.

Another way of looking at this situation is that if your code base has a lot of code smells or bad design decisions that make it difficult to add new features at the same rate as you are used to, then you know there is something getting in your way and bringing down your efficiency. In this state you realize that you have borrowed way too much time from the system by cutting corners. You have not paid back the system by investing regularly in cleaning up the code base.

Even thought this metaphor is really powerful in conveying the messaging that if you continue to hack code, after a while the code and its design will get in your way and stop you from making any real progress due to the heavy interest rates you’ll end up paying.

As Martin points out

The tricky thing about technical debt, of course, is that unlike money it’s impossible to measure effectively. The interest payments hurt a team’s productivity, but since we Cannot Measure Productivity, we can’t really see the true effect of our technical debt.

Also what I have noticed on lots of teams is rarely a developer intensionally introduces technical debt. Today’s quick fix turns out to be a bad hack and that leads to adding to the technical debt. Also like financial debt, technical debt builds up slowly without the team members realizing it. Since you cannot directly measure Technical Debt, the only time you realize you have technical debt is when its too late.

If you really think about it, Technical Debt is a lot like Pollution. Like pollutants in the environment, quick fixes and hacks, degrades the system in which they live. They constantly bring down developer’s ability to build new features (harm people living in the affected area). Pollutants gradually affect people and as time passes by, makes it exponentially harder and costly to fix it.

What is interesting about the pollution metaphor is that few years back who realized CO2 leads to pollution and global warming. But today its all over the place. People driving 2 stroke vehicles never realized that they were polluting the environment. Similarly, few years back who realized Switch Statements are considered harmful? Now with so much emphasis on Code Smells, we can think about these things and avoid some of them.

Also like Pollution, one person introduces a hack into the system and all it’s neighbors (team members and customers) suffer from it. Note that you don’t suffer as soon as you introduce it, its only after delta T that you start feeling the pain.

The biggest problem I find in dealing with Technical Debt is that one man’s elegant solution might look like another man’s hack. Terms like “clean”, “simple” are very relative. To make matters worse, today’s elegant solution might look like a hack tomorrow to the same person. We constantly keep learning better and simpler ways to do things. Tools and languages are constantly improving and getting powerful. What bothers me the most is that people talk about Simplicity as if it were one thing. Unfortunately, simplicity is not as Black and White as I would have liked it.

  • http://www.m3p.co.uk/blog Steve Freeman

    Interesting metaphor, especially the bit about how people can pass their problems on to someone else, and how an unpoliced system encourages cheating (consider the mess in Napoli at the moment).

    I’ve always thought that the examples in MSDN (the ones that everyone copies into their production code) are the CFCs of MS development. Even if they fixed them all today, it would take at least a decade for the mess to dissipate.

  • http://www.m3p.co.uk/blog Steve Freeman

    Interesting metaphor, especially the bit about how people can pass their problems on to someone else, and how an unpoliced system encourages cheating (consider the mess in Napoli at the moment).

    I\’ve always thought that the examples in MSDN (the ones that everyone copies into their production code) are the CFCs of MS development. Even if they fixed them all today, it would take at least a decade for the mess to dissipate.

  • http://agilefaqs.com/nareshjain.html Naresh Jain

    I think we either need a policed system or self-disciplined team members to avoid these issues. Unfortunately what I have found so far is that most humans (at least in the software industry) are not as self-disciplined as most good Software Development methods requires. So may be you are right, a policed system is what might work. But I hate the sound of policed system, esp. externally policed systems. Reminds me of the CMM days when we had all those crazy Process Police floating around doing nothing other than causing pain to people trying to build software.

    With CI and analysis tools for Code Coverage, Cyclomatic Complexity, Dependency Management, Check Style, Aspects, etc I wonder if we can build a self-policing system. I’ve had some success with this approach. But there is a long way to go.

  • http://agilefaqs.com/nareshjain.html Naresh Jain

    I think we either need a policed system or self-disciplined team members to avoid these issues. Unfortunately what I have found so far is that most humans (at least in the software industry) are not as self-disciplined as most good Software Development methods requires. So may be you are right, a policed system is what might work. But I hate the sound of policed system, esp. externally policed systems. Reminds me of the CMM days when we had all those crazy Process Police floating around doing nothing other than causing pain to people trying to build software.

    With CI and analysis tools for Code Coverage, Cyclomatic Complexity, Dependency Management, Check Style, Aspects, etc I wonder if we can build a self-policing system. I’ve had some success with this approach. But there is a long way to go.

  • http://ethicminds.blogspot.com/ kyaw kyaw naing

    Technical debt hits the bottom line real hard. Here is one way it does.
    Even when I am excited about the features in the prototype, I feel exhausted to clean up my own quick and dirty code.

  • http://ethicminds.blogspot.com/ kyaw kyaw naing

    Technical debt hits the bottom line real hard. Here is one way it does.
    Even when I am excited about the features in the prototype, I feel exhausted to clean up my own quick and dirty code.


    Licensed under
Creative Commons License