[fsloth]

I don't disagree with the article, and I don't disagree with you - I'm more of expanding the ideas you discussed.

I think the key here is indeed that technical debt should not be used as an excuse to write poor code.

But I think it may be hard to systematically tell apart code that was written intentionally fast and poorly, and code that just was written to explore the market.

It "is accepted" that the most of the cost a software comes from the maintenance period - adding bugfixes, new features, and just reading the code.

If the software can be moved from point A where these costs are high (including risk of things getting broken due to complex architecture) to a point B where they are lower, then I could say "technical debt is paid back".

Was the software in point A due to intentional shortcuts, or just because that's how we write software in an unfamiliar territory, is maybe besides the point in gauging the practicality of the term.

The "technical debt" gets anyway accumulated due to the empirical quality of most of software engineering process.

I think this is the most critical thing people should realize - don't take short cuts unless the house is burning down - but do try to explore the problem space fearlessly.

The exploration is due to incomplete understanding of the end user needs. And sometimes you can't really explore that space without delivering something to the user.

But!

I think the exploration phase does not necessarily need to incur technical debt if it's done using prototypes that won't end up in production (yeah yeah like that's ever happened but in theory...).

In this case the deliverable will be just used as a template for the actual product development, with the result that the product may be in a more mature state from the get go, and hence, have less debt from the start.

Should the exploration be done with prototypes or actual vertical slices of production software? I suppose this depends on the situation. Sometimes the problem is actually so hard that you need to deliver a build based on an actual production codebase no matter what.

[rorykoehler]

It's not poor code it's just code that prioritises shipping now over writing for some hypothetical future state.

[fsloth]

I think in general writing code based on hypothetical requirements that never materialize is just wasteful. And leads to bad code.

You can ship good code fast.

Shipping slow is not a guarantee of good code.

I think the pathology here is defending "sloppy" or "negligent" code by the need to ship fast, when in fact you probably could ship as fast with cleaner code, but the coder just could not care enough.

[Retric]

This isn’t about knowing what changes will be made just that change is inevitable. Technical debt arises because it’s faster to write brittle code.

The problem with brittle code is it makes any change more difficult. The most obvious example is variable names without semantic meaning. The compiler doesn’t care if you’re using “asdf” but such choices collects its pound of flesh every time anyone messes with that section.

[rmetzler]

Yes, I 100% agree and would like to add to your argument.

Another example of technical debt is when you write code without tests. You’ll probably finish much faster in the first week or two and then the manual testing will take more and more time. But how often did we see code bases without tests? All the time! And the managers don’t realize how much money they could save by focusing more on quality instead of features.

If you think you‘ll just implement this one thing and then never touch the code again, chances are high you‘ll just hack up the thing and copy paste some code everywhere until it kind of works. This is increasing technical debt, you take out a loan and someone in the future has to pay it back IF they want to make a change. But this is almost always the case, even if you don’t know it now.

My definition of technical debt I wrote down before reading the article: technical debt is the inability to make changes due to not making changes (on a conceptual layer) before.