Agile Zone is brought to you in partnership with:

I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Have You Found Your Project In Technical Debt?

10.21.2010
| 7258 views |
  • submit to reddit

I've been reading a lot about technical debt recently where people alternate between voluntary technical debt or inadvertant debt. Without doubt, every project has some level of debt, but the important thing is how much do you have, and when do you plan on paying it off.

Martin Fowler says

"Technical Debt should be reserved for cases when people have made a considered decision to adopt a design strategy that isn't sustainable in the longer term, but yields a short term benefit, such as making a release. The point is that the debt yields value sooner, but needs to be paid off as soon as possible."


Technical debt is an excellent way for an architect or developer to communicate the cost that a particular decision or implementation made in the short term will affect the project in the longer term.

While in words this works fine, I wonder if there is some type of formula that we can apply to illustrate and track the debt of a project. For each item in the project that causes some debt, it needs to have interest (the cost of not addressing it) and principle (the cost of refactoring the issue to make it work).
While principle could be the number of man days to fix it, I'm stuck with how to express the interest. And how do you work out how much technical debt a project can actually afford. I'm interested to hear if any of you have used the technical debt metaphor in your projects effectively?  

There are different types of technical debt, which Martin Fowler describes very neatly in his quadrant diagram:


Reckless and Deliberate

The cost of racing making the deadline at all costs. Once it runs it's ok right?

Reckless and Inadvertant

Creating a mess without noticing that they've done so. Without bringing in any design patterns or real knowledge/experience, debt it going to happen, without the team realising how much of a mess they've created.

Prudent but Inadvertant

"If I was starting again, I'd do it differently". While things were done to the best of the teams ability, we find that there will be a better way.

Prudent and Deliberate

Voluntary debt. The team knows that it's not quite right, but it's better to ship and accept the technical debt that will arise because of this.

In this poll, I'd like to see what is the most common type of technical debt in projects you have worked on.

Comments

Richard Deadman replied on Thu, 2010/10/21 - 8:40am

As much as I like quadrants and their accompaning graphics, I'm not convinced of the difference between "reckless and inadvertant" and "prudent and inadvertant". Inadvertant means that you don't realize you are doing something, and if you don't realize you are doing something, it is hard to assign motive (reckless or prudent) to what you are doing.

If you are pulled over for speeding and know you are speeding (deliberate), then the question is "was it prudent?" (my wife is in labour) or "was it reckless?" (I like speed). If, however, you weren't looking at the speedometer or didn't know the speed limit (inadvertant), how can you further categorize this as reckless or prudent? You never decided to speed in the first place.

Jason Erickson replied on Thu, 2010/10/21 - 12:40pm in response to: Richard Deadman

I was going to answer this poll as Reckless and Deliberate but then I ran into a different problem.  What I was thinking of as Reckless and Deliberate does not really fit well, either.  I have often worked in environments when the stakeholders would say "I know the problems with doing it that way, but we have to get it out the door.  We don't have [time|money] for [[more|any] testing|fixing those bugs that we found|flying the product manager out to sit with the team for a while]."  So they are being deliberately Reckless, but actually while developers may believe that, the stakeholders think they are being Deliberate and Prudent because they kind of know they've said, "I understand the risks - do it anyway." But then when a demo doesn't perform well or an important customer runs into an embarrassing bug, they ask, "How could this happen?" The answer, "You asked for these risks," is not very satisfying.

 To bring the speeding analogy back in, a 40 year old driver with a good driving record who is speeding to get to an important meeting or to get to the hospital is probably being Deliberate and Prudent.  However the teenager who is driving 100 mph racing his friend on the interstate usually knows it is dangerous.  He'll say things like, "I know it's dangerous but I live for the thrill."  In some ways he is making a deliberate, conscious trade-off of safety for thrill.  However, he is too young and inexperienced to really understand the degree of risk and potential costs he is taking in that trade-off.  So is he being deliberate and prudent because he is voluntarily accepting risk, deliberate and reckless because he is voluntary accepting a lot of risk, inadvertently reckless because he accepts the risk but doesn't really understand how much risk?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.