I don't really believe this although it seems rather hard to prove which side of this debate is right. Presumably it also depends on circumstances. I think any sort of messy or bad code immediately slows down developers. The truism that code is more often read than written comes to mind. This 'devivering business value' thing also sounds doubtful to me. Any sort of bad code is a breeding ground of bugs. So you have completed three stories this sprint and hence delivered three items of 'business value'? Sounds nice but it may not be so great if two of them are going to break in the near future because of code quality issues. In that case it maybe is just not true that three items of business value were delivered. In the context of bad coding practices it kind of becomes unknowable how many items of business value were delivered.
I kind of despise the term 'technical debt'. It seems that in the beginning it was introduced to make the business side take code quality issues more seriously by likening them to something they could understand, i.e., debt, but now it seems to function as a way to postpone the fixing of issues, perhaps indefinitely. I think most things that go under the moniker of technical debt have an interest rate that is far higher than any business would enjoy taking out in terms of a loan.
Let me give an example. Some code can be badly formatted. This hardly costs any time to correct but maybe it is also not worth it? Well, I once encountered some code that clearly was in the wrong function, so I asked the colleague who tends to know about that part of the application. Then it turned out it actually was not in the wrong function but instead there was no blank line between the two functions making me not notice that it was actually two function instead of one. In the mean time I had disturbed a colleague which also has a real cost in terms of getting back into whatever he was busy doing. All code quality issues have costs associated to them that are very difficult to know beforehand but I think the safer way is to always be improving code quality and that which is called the internal quality of software should actually just be maximalized and that technical debt most of the time has more costs than benefits and that the costs will come sooner than anyone expects, long before you MVP is actually finished so that you might actually have paid it off profitably beforehand.
Badly formatted code is hardly a true form of tech debt. Especially considering all the automatic tools like prettier out there today.
Tech debt is getting a feature out there, asap by creating work around that normally would require some refactoring.
In a lot of cases, it is forgoing optimization. We have several places in our app where we need to refactor some of our database tables in order to properly join the data and get it in an efficient manner.
But that will take a few days of refactoring and testing so instead, we just query the missing data in a subquery 200 times or whatever.
For now, it works fine, but as the dataset grows, that will obviously become slow and expensive.
But by then, we will have more customers and more budget and hopefully more developers that we can afford to refactor that code.
If we had unlimited time and resources, sure, go ahead and refactor your entire codebase every time you add a feature.
You'll build an amazing company, assuming your customers pay you based on how awesome the source code is, rather than what it can do for them right now.
I kind of despise the term 'technical debt'. It seems that in the beginning it was introduced to make the business side take code quality issues more seriously by likening them to something they could understand, i.e., debt, but now it seems to function as a way to postpone the fixing of issues, perhaps indefinitely. I think most things that go under the moniker of technical debt have an interest rate that is far higher than any business would enjoy taking out in terms of a loan.
Let me give an example. Some code can be badly formatted. This hardly costs any time to correct but maybe it is also not worth it? Well, I once encountered some code that clearly was in the wrong function, so I asked the colleague who tends to know about that part of the application. Then it turned out it actually was not in the wrong function but instead there was no blank line between the two functions making me not notice that it was actually two function instead of one. In the mean time I had disturbed a colleague which also has a real cost in terms of getting back into whatever he was busy doing. All code quality issues have costs associated to them that are very difficult to know beforehand but I think the safer way is to always be improving code quality and that which is called the internal quality of software should actually just be maximalized and that technical debt most of the time has more costs than benefits and that the costs will come sooner than anyone expects, long before you MVP is actually finished so that you might actually have paid it off profitably beforehand.