Are bugs part of technical debt?

Question

Our Scrum Master keeps referring to bugs as technical debt. Is he right, are bugs considered to be technical debt in the world of Agile?

Why is it important to decide if they are technical debt or not? Will it affect how you represent bugs on your scrum board, or affect how you plan to fix them? — Bryan Oakley, Aug 03 '13 at 11:55
@BryanOakley Some bugs can block you in such a way that forces you to work around them, introducing even more technical debt. These bugs may be too expensive to fix — BЈовић, Aug 03 '13 at 11:58
@BryanOkley - I always thought technical debt was design or refactoring that was needed to improve the implementation but not possible at the present time due to time/budget constraints. I think it is important to use the correct terminology. I might be wrong or he might be wrong, which is why I asked the question. — user86834, Aug 03 '13 at 12:10
I understand that. Why is it important to call them technical debt? Are you saying that if you classify them as "technical debt" that you'll treat those bugs differently than other bugs? — Bryan Oakley, Aug 03 '13 at 12:11
@BryanOakley No, as I said bellow, I wouldn't mix technical debt with bugs. For such bugs, I would assign time to pay back part of technical debt that is blocking further development. That should help with fixing bugs (if it doesn't fix them) — BЈовић, Aug 03 '13 at 14:36
You can have a huge amount of technical dept and not have a single bug. Technical dept is the opposite of well written and well designed code. Well written code is easy to maintain, test, and add to. Technical dept slows down development, makes it difficult to track down bugs, and increases the chances that new code will introduce bugs. — Luis Perez, Nov 20 '13 at 18:26

Murph · Accepted Answer · 2013-08-04T18:52:33.937

40

I think the answer here is fairly simple - the key feature of technical debt is that its something we incur by choice.

We choose to make architectural, design or implementation decisions that we expect will cause us issues later in order to achieve specific objectives sooner.

A bug is not something we choose to have in our code - so de-facto its not technical debt.

Of course one can make all kinds of interesting (and possibly valid) arguments about choices made post discovery but fundamentally (and particularly in the context of the question) no, bugs are not technical debt - sounds more like abuse of buzzword bingo to me.

As a postscript - I don't agree with the assertion that its a given that technical debt will lead to bugs in and of itself as that makes far to many assumptions about the nature of the choices made. For example you can have well written, well structured, test covered code that still makes - say - architectural compromises for early delivery. Similarly you could choose not automate your deployment processes which won't lead to bugs but will probably lead to a lot of stress and pain. Of course if the debt is that you've written code that's not SOLID (or whatever) then yes... but that's by no means always the case.

edited Aug 04 '13 at 18:52

answered Aug 03 '13 at 14:24

Murph

7,813
1
28
41

1

+1. I think BЈовић's answer is pretty much right, but your answer really hits the nail on the head. (I'm a bit confused by your use of the term *de facto*, though. I don't think you can be saying that *de jure*, a bug *is* technical debt?) – ruakh Aug 03 '13 at 16:25
Use of language is such fun... try this: http://en.wikipedia.org/wiki/De_facto - read it as "for all intents and purposes" which is close enough to my intent – Murph Aug 04 '13 at 18:43
"I think the answer here is fairly simple - the key feature of technical debt is that its something we incur by choice." Where did you pull this definition from? I don't think it's right. That's one part of technical debt, the other part is implicit and is usually due to ignorance and bad practices. – gphilip Jun 06 '14 at 20:39
de jure du jure. Tomorrow de facto. QED. – radarbob Jun 07 '14 at 01:58
@gphilip its my opinion (based on my experience). I think that the *implicit* stuff as described is still effectively generated by "choice" - its an interesting question to what extent one might describe it as technical debt 'til its recognised, acknowledged and then left unchanged – Murph Jun 07 '14 at 09:41
@Murph this is a good article to support my argument: http://www.fusionalliance.com/development/the-three-types-of-technical-debt/ – gphilip Jun 08 '14 at 17:31
1

according to Technical Debt Quadrant by Martin Fowler you can identify bugs and bad code as "reckless inadvertent" debt :http://martinfowler.com/bliki/TechnicalDebtQuadrant.html . I think the point is that if you mark some sensitive bugs as debt then you can understand how much they cost you and whether or not you need to eliminate it. Eg, is you have sloppy written module that is changed only once in a year and it would take weeks to rewrite it - you probably should keep it as it is because interest payment on this debt are very very small – shershen Aug 26 '14 at 12:43
A technical debt is a debt that must be paid with "time". If a bug never consumes any "time", then it is not a debt. If a bug consumes time, then it is a debt. Every time the bug creates an issue, it consumes time. Every time someone rediscovers the bug, it consumes time. Fixing a bug also consumes time. I can't think of a situation that a bug isn't a debt of time. – Bengie Jan 04 '16 at 20:27

score 23 · Answer 2 · edited Apr 12 '17 at 07:31

Yes.

Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase.

Source: Wikipedia

Read technical debt as something you could have avoided by having a better workflow (for example doing architecture properly before jumping to coding, doing TDD, etc.), better coding practices, etc.

Most bugs could have been avoided by additional review or the usage of more formal methods. By not doing everything you can to not having bugs in the first place, you lower the immediate/short term cost of the project, but increasing the technical debt.

After reading the answer by BЈовић, I see that it may not be as easy as I thought.

For example Are bugs part of technical debt? article claims that only bugs you know about but decided not to fix are part of technical debt.
Another example, Christopher's Thoughts on Technical Debt qualifies bugs as the result of technical debt, not part of it. This being said, many of the listed results, like "cost to implement new feature", are influenced by the number of bugs.
Finally, when creating ABCDE-T model of technical debt, I included bugs as one of the six factors, but they are considered differently. The focus is not on the bugs themselves, but on the ways they are collected, prioritized and solved. Bugs themselves appear as the result of technical debt (like in the previous example), but never appear themselves as a factor of technical debt.

This being said, I'm still inclined to answer that bugs —any bugs— are part of technical debt.

First argument:

Reading Jeff Atwood's quote, most bugs would qualify as:

the extra effort that we have to do in future development because of the quick and dirty design choice

In business applications, nearly every bug comes from either quick and dirty design choice or bad practices (would it be the lack of testing, the usage of technologies the developers don't know enough, lack of communication, lack of understanding of the domain, etc.) This means that "by refactoring the quick and dirty design into the better design" and by adapting better practices, businesses could solve most of their bugs.

Second argument:

If we make a parallel between the ordinary debt of a company which is important to take in account when a company is sold to another, and the technical debt, which is equally important to take in account when a project is sold to another company or given to another team, we can easily see that bugs are part of the technical debt, since the new team would:

Either have to deal with those bugs before making new features (point 5 of Joel Test: Do you fix bugs before writing new code?)
Or keep the bugs, preserving/increasing this way the technical debt.

I personally don't think of defects as technical debt even though the argument presented in this answer is sound, but a) it doesn't really matter how we define technical debt IMO, and b) this is such a well written answer I'm voting it up anyway. +1! — Bryan Oakley, Aug 03 '13 at 11:52

BЈовић · Answer 3 · 2013-08-03T11:53:03.847

14

Jeff Atwood in his article Paying Down Your Technical Debt gives quite nice answer on what technical debt is :

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.

Strictly speaking, bugs are not part of technical debt, if they do not slow down further software development (changing things, adding new features, etc). They are software defects.

However, when it is too expensive to fix a bug, or it forces you to work around it (and introduce even more technical debt), then it becomes part of a technical debt.

edited Aug 03 '13 at 11:53

answered Aug 03 '13 at 08:33

BЈовић

13,981
8
61
81

1

Actually they do, because bugs may lead extra work arounds on new features that would not be necessary without the bugs. I have even seen code evolving in a bad direction (building up more technical debt) because of a bug that somehow evolved into a "it is not a bug it is a feature" because customers wrote scripts or whatever that relies on the buggy behaviour. – Marjan Venema Aug 03 '13 at 10:05
@MarjanVenema Good point. I haven't thought of that. – BЈовић Aug 03 '13 at 11:46
1

Note that this quote is not from Jeff Atwood, it is taken from [a post of Martin Fowler](http://martinfowler.com/bliki/TechnicalDebt.html). Jeff quotes this as well in his blog post. – Uooo Aug 07 '13 at 08:54

score 6 · Answer 4 · answered Aug 04 '13 at 01:59

A bug is not technical debt. Technical debt is skimping on quality, not the absence of it. Software should not be delivered with bugs in it in the first place. You know, that whole working software over comprehensive documentation thing.

The biggest offenders of technical debt are "temporary bug fixes", you know the ones you put into to pass the test and get the story accepted The ones that that you have promised yourself you will refactor later, but then never do. As these temporary fixes, patches and other things accumulate, the code becomes unnecessary cluttered, difficult to update and test and in general is a nightmare, but it still does it's job.

For support of this opinion, I went straight to the source, Ward Cunningham. Regarding this, Ward did a good interview a while back with Capers Jones, it's worth a watch.

Technical Debt Debate, with Ward Cunningham & Capers Jones

Another article worth a read is by Martin Fowler

Martin Fowler on Technical Debt

Within Martin's article, please find the link to the original mention of technical debt by Ward Cunningham, from OOPSLA92:

The WyCash Portfolio Management System

A quote from the above article:

Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt.

In the end, Technical Debt may have come to include bugs for some folks, and I guess that's fine. I just don't think that was the original intention.

"Software should not be delivered with bugs in it in the first place." All software but the very simplest program contains bugs. You set this bar too high. — bhspencer, Aug 01 '16 at 14:37

Stephen C · Answer 5 · 2014-06-08T01:21:00.880

In my opinion, it really doesn't matter whether you say that bugs are part of technical debt ... or not.

The plain fact is that existing bugs represent extra work that may need to be performed in the future, either to fix them or to work around them.

Technical debt (as the label is typically used) also represents extra work that may need to be performed in the future ... one way or another.

So whether you say known (or unknown) bugs are technical debt ... or not ... is really just a matter of definitions. And since there is no authoritative definition¹ of "technical debt", the whole discussion is kind of pointless.

As Lewis Carroll wrote:

'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.'.

That's actually how natural language works. Words mean what people think they mean. Dictionary definitions and so on merely document the way that words are used, and they are not necessarily accurate documentation. If your Scrum Master wants to refer to known bugs as technical debt, who is to say that he is "wrong"?

^{1 - Quoting people such as Ward Cummingham and Caper Jones does not help either. At best it tells us what they mean (or meant) when they use (used) the phrase. They don't "own" the phrase. While they are undoubtedly authorities on these issues, this is still just their opinion.}

score 3 · Answer 6 · answered Aug 04 '13 at 10:08

Strictly speaking, the answer to your question is No.

Technical debt can (and probably will) lead to bugs, but concluding that any bug is the result of technical debt is putting an interpretation between two facts: there's a bug and there's technical debt (assuming that can be concluded as fact).

If your Scrum Master is stating 'as a theory' that bugs are the result of technical debt, he is cutting corners. If he is saying this about specific bugs that keep re-appearing he may well be right - we cannot see the code quality from here ;-)

He may also have an ongoing complaint about people not listening to him about the technical debt, and therefore labeling every bug as technical debt, but now I'm speculating.

Are bugs part of technical debt?

6 Answers6