Technical Debt

Technical Debt and Accountability

Technical Debt and Accountability

I am wrapping up my second in a series for Clean Coders on Technical Debt. In the first episode, I explain the Technical Debt metaphor, how it originated, how it changed over time, and how it now is commonly understood in a way that is the opposite of what it originally meant. I talk a bit about the limitations of metaphors and how debt in particular has not served us well as a metaphor over time. So when a link to an article on the "Limits of the Technical Debt Analogy" hit my inbox this morning, I was quick to follow the link and see what the author had to say. 

Unfortunately, this article is not at all about the limitations of the metaphor. The article is about how people other than those who write the software are responsible for the quality of the software. This article is bunk.

Code Profiling

Code Profiling

I recently gave a talk on the role of a Quality Analyst as an organization transitions from waterfall to agile. The talk was entitled "Switching Horses in Midstream" and covered a number of topics. One item in particular struck me as worthy of blogging about. It's a technique I've been using for years, but have never written about it. So here we go:

Legacy code bases with a lack of test coverage are often trepidatious places to hang out. You never know when a simple abstract method is going to create a sink-hole of logic and reason, eventually leading to your exhausted resolve to revert and leave it dirty.

"Necessary" Refactoring

In a discussion on the Agile Alliance Linked In Group, Michael Moles asked how refactoring fit into the agile process.

The Question

Refactoring: How does it fit into your Agile process?

We are in the midst of writing a new product, at this point the developers are realizing that some of the code should be refactored to improve performance and or clarity for ease of use. How do you fit refactoring into you Agile process? We have created separate backlog items for refactoring specific pieces of code. These backlog items are treated exactly like any other backlog item (meaning they have effort assigned and are committed to sprints by the team). What do you do when refactoring is necessary?

Should we always pay back Technical Debt?

A former coworker of mine, Jim Highsmith, has recently written an article on The Financial Implications of Technical Debt. Jim states that recent studies indicate the cost of technical debt is near $1 trillion in the U.S. I would like to see these studies. I do know that not too long ago, Gartner released a report indicating that the worldwide cost of IT Debt will be $1 trillion by 2015. Regardless, the point he makes is still valid - technical debt is egregious.

Jim states, "Unfortunately, by the time many organizations are paying attention, all the solutions are bad ones: 1) do nothing and it gets worse, 2) re-place/re-write the software (expensive, high risk, doesn’t address the root cause problem), or 3) systematically invest in incremental improvement."

Of these three (bad) options, I think the second is often a better choice than the third. The first represents failure to make a necessary decision.

Code as a Cause of Project Failure

During the speaker panel at SCNA this past weekend, Chad Fowler (@chadfowler) asked, "How many projects fail because of the code?". Given the context, I assumed he was making the point that projects fail due to business issues, not code. The room was silent. While one might have assumed this meant the entire group thought it rhetorical, I concluded everyone agreed with Chad. Projects fail not due to code, but due to business issues.

The Technical Debt Trap

I had the honor of presenting at Chicago Code Camp this week on the topic of technical debt. For those of you who know me, you know this is a topic I feel passionately about. More accurately, I am concerned about the misunderstandings surrounding technical debt and the frequent use of the term to placate any sense of responsibility over writing messy code in pursuit of a deadline.

Martin Fowler on Technical Debt

Martin Fowler on Technical Debt

Martin Fowler just posted an article on Technical Debt in which he discusses the Technical Debt Metaphor. Fowler argues that the metaphor should (and does) include messy code. He talks about deliberate and inadvertent debt as well as reckless and prudent debt. Prudent and Deliberate is the most desirable. While Reckless and Inadvertent is the least desirable. He published the following quadrant to help explain his concept.

Messy Code is not Technical Debt

Technical Debt is a common topic these days. How is it incurred? How should we track it? When should we pay it down?

It is a metaphor commonly understood. Our customers get it. While they may not like it, they do understand. Technical Debt is incurred today and needs to be paid down; preferably sooner rather than later what with compound interest and all that.

Don't be like "Ted"

I have a friend; Let's call him "Ted".

Ted's place is a mess. Frankly, it's a disgusting, blatant, offensive, inexcusable mess. I visit Ted on occassion. He has a nice family. They're good people. Yet they live in near squalor and seem to be relatively unbothered by it. Ted complains regularly, but knows that sometimes there are circumstances beyond our personal control.

Allow me to share with you a few of Ted's household issues.