Comments on: Finding the value in fixing technical debt

By: Michael Norton

Michael Norton — Tue, 01 Sep 2009 23:02:22 +0000

Technical Debt is attributed to Ward Cunningham and it is important to note that Ward was talking strictly about how our understanding of the domain evolves, thereby creating the need to refactor.

http://docondev.blogspot.com/2009/08/messy-code-is-not-technical-debt.html

By: Paul A Houle

Paul A Houle — Mon, 12 Jan 2009 19:48:56 +0000

Developers who spend time fixing “Phantom Debt” can be a big problem. They not only waste their own time fixing problems that don’t need to be fixed, but they waste the time of other developers that need to fix bugs introduced by superfluous changes.

By: Brian Marick

Brian Marick — Mon, 12 Jan 2009 15:11:28 +0000

I’m pretty sure the term “technical debt” is due to Ward Cunningham. One important part of the analogy – one that I’ve often forgotten – is that debt can be a useful tool. I believe Ward has talked about the business having an aggressive goal that the team can’t meet in the desired time with its usual level of code cleanliness. In that case, the business – in conversation with the team – might rationally decide to take on a particular level of debt, *knowing that they’d have to pay it back with interest later*.

When we talk about technical debt, we talk about it as if the interest will never be paid and debt will continue being taken on until the program becomes “bankrupt”. That’s certainly not uncommon, but the alternative of well-used debt is also an interesting one to think about.

By: Arjan`s World

Arjan`s World — Sun, 11 Jan 2009 16:58:32 +0000

[...] Finding the value in fixing technical debt -Mark Needham ‘ There is a bit of balance between making the code perfect and adding value to the customer ‘ [...]

By: What kind of college degree should you pursue to go into the sales field of renewable energy? ? | The Solar Truth

Sun, 11 Jan 2009 08:20:06 +0000

[...] Finding the value in fixing technical debt at Mark Needham [...]

By: Mark Dalgarno

Mark Dalgarno — Sat, 10 Jan 2009 13:19:59 +0000

Ongoing maintainability is of value to the customer and the organisation but it’s hard to measure and customers never ask for it explicitly in my experience.

Its value comes from reduced time to understand the software, less chance of introducing buggy code and from reduced code complexity. These all have direct benefit to the customer in terms of delivering a better product faster.

We term the gradual build up of technical debt as ‘software erosion’. In my ‘When Good Architecture Goes Bad’ workshops (http://blog.software-acumen.com/2008/06/05/examples-of-software-architectural-decay/) I always ask the audience who’s responsible for stopping software erosion. Most people recognise that they themselves have a responsibility for this and that as technical people they need to make their managers aware that their software is eroding and somehow convey the size and effects of the problem. (This is a hard problem )

I’ve just invited you to a Google group discussing the problem of software architecture decay. The idea is to find common examples of decay, find practices that help slow decay and come up with some tools for helping technical people convey the size and value of the problem to their managers: http://tinyurl.com/9wg6c5