[charles_f]

A) big part of the article is about the fact that the current tribal meaning of the term deviated from the meaning that the first person to use it had. This is somewhat of a semantics argument, like "hey you're using that in a commonly accepted way but Ward C didn't mean that so you're wrong".

B) article points that you're accumulating debt to get speed to market or because of incomplete knowledge of the market at some point and uses this to say "it's not technical because it's business". But it is technical because, well, it is issues with your technology. That you borrowed on your tech stack for business reasons doesn't make it less technical

C) ironically I'm arguing on semantics because I find the title to be semantically wrong. In fact I largely agree with the point of view, tech debt is the result of a strategy, be it that you want speed or low cost. Sometimes it makes sense for the business, and as long as the strategy is conscious and explained, and that we're clear with the consequences, I'm fine with it. In my experience most of the time it's not an assumed strategy and we dont want to deal with the consequences.

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

[afarrell]

> This is somewhat of a semantics argument

It is important to occasionally have arguments to clarify semantics so we maintain the meaningfulness of our language. Otherwise, we lose the ability to communicate.

Some people believe that meaningful communication is unimportant. Those people are wrong.

[pdimitar]

We should periodically make sure we use common terms, yes, but I find the author's tone hugely inappropriate. He seems a bit rebellious against the notion of "technical debt to the masses means something else than it means to me".

Statistically and historically speaking, he's waging a losing battle and I find myself not interested about what he believes technical debt is.

Furthermore, what academia thinks of technical debt is seriously irrelevant. Academics don't write code for a living. Their take on this matter isn't super important.

[afarrell]

> what academia thinks of technical debt is seriously irrelevant. Academics don't write code for a living. Their take on this matter isn't super important.

I initially agree strongly, but then I remember that labs maintain FORTRAN codebases for years. So I'm curious about their view of technical debt, but its definitely in a different context.

[gopher_space]

I have some experience with older financial and edu systems, and it's definitely a different perspective (from my perspective).

If you have a system that's been modified to handle every edge case encountered in the last decade, and it works, and other people rely on it to do their work, your perspective switches to maintaining the environment the system operates in.

You're looking at automation continuously built around processes that might predate electricity. The interfaces are ingrained into the organization. Other organizations rely on these interfaces and sometimes there are legal responsibilities.

It's a longer-term perspective. Tech debt isn't a crisis, it's an eventuality you try to encapsulate.

[pdimitar]

I agree that there used to be an overlap between an academic and a programmer. But as you pointed out, it hasn't been the case for a long time.

Plus, I'm not really sure good practices mattered to them even back then. Academics, whether they're programmers or not, chase different goals and have other incentives.

Like you, I'd love listening to one of them one day (if anyone speaks up). I'm sure there will be a few pearls of wisdom in such a shared experience.