Are bugs part of technical debt?

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?

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.

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.

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.

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.

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.

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.}

Filed under: softwareengineering - @ 18:36

Thẻ: agile, technical-debt

Thiết kế website giá rẻ

Danh mục

Are bugs part of technical debt?