[Pamar]

I am not sure that your metaphors actually work when talking about "Technical Debt" in the IT sense of the word.

- If the contractor finds asbestos *which was put in by the contractor himself because using asbestos was legal (and cheaper) up to 2 years ago"...

- If the mechanic that sold me my previously owned car without telling me that servicing would be more expensive in the future...

- If the lawyer who was originally part of the team that helped draft the old law...

etc.

[alanwreath]

I must not understand technical debt...all of the scenarios you're mentioning seem like they could easily map to a technical debt scenario

- a developer takes a certain strategy that is no longer valid (even technical debt that isn't recognized early on as being something that will have to be changed more than likely soon, is still technical debt in my mind -- your ability to recognize technical debt early on just means you know you're incurring it)

- developers often incur technical debt without explaining to stakeholders about it because a) they don't care b) they don't think the stakeholders care c) they want to get the work done and not get dinged

- developers who have to pay for technical debt may be the creators of that debt to begin with...(of course, I'd wager that most technical debt is handled by someone else who comes later because I'm rarely given the chance to fix problems I created, project managers can be judgmental like that - and project managers have to be convinced that we can just apply some more duct tape)

[Pamar]

See my other answer below: trying to convince the payers that there are extra costs due to "technical debt" accumulated somehow during the lifetime of a sw project would sound "unconvincing" because from the point of view of the business that would be part of the job of the same people that are now asking more money/time/resources to fix it.

[Notanothertoo]

This reads like it's in a vacume and assumes the business requirements were comunicated, they were clear, and and static. None of which is reality. Additionally things get updadated and need con rant maintenance. Gone are the days of writing code and letting it run untouched for years.

Tech debt usually occurs when the people implementing it aren't aligned with the with the stakeholders.

[valbaca]

> - If the contractor finds asbestos which was put in by the contractor himself because using asbestos was legal (and cheaper) up to 2 years ago"...

Obviously someone* put that there. It didn't just install itself. Regardless of whether the contractor installed it themselves or not, the reality is it's there now and needs to be removed.

In other words, the analogy still holds regardless of "oh they put it there"

> - If the mechanic that sold me my previously owned car without telling me that servicing would be more expensive in the future...

That is exactly what every car dealership does with their "powertrain" warranties and service packages.

> - If the lawyer who was originally part of the team that helped draft the old law...

AAAAAAAHHHAHAHAHHHAHAAAA New to the legal system?

[Pamar]

It was a way to illustrate the metaphor: I am just as "new to the legal system" as I am at asbestos removal or car repairing... but I have enough experience with software development to understand why "tech debt" is a pretty hard concept to sell to business.

In any case my point is not "there is no tech debt if you created it yourself" it is more about "from the point of view of business tech debt is not something they care about: it is sonething they expect to just be sorted out transparently or that should not even happen". After all, Microsoft never bills them for "tech debt", it just ask them to reboot to update their laptops, no?

I am not saying this is fair, or right. I am just trying to explain why mentioning "tech debt" falls on deaf ears.

[xionon]

I don't understand your point here. In literally all these scenarios, you would still be billed, and it would be appropriate.

[Pamar]

My point is: technical debt from the point of view of Business is something that the developers themselves introduced or did not manage properly, so trying to make it look like something beyond their control ("we just found out that in the 70s someone put asbestos under the roof") will sound a bit unconvincing.

[lucasyvas]

Totally on point, but if I may offer a twist:

Say you run a large plumbing company, and you discover your plumbers took shortcuts on a particular job that resulted in an abundance of leaks for a given project.

The plumbing company cannot ask the plumbers for their pay back. They will have to eat the cost and fix the plumbing.

So, it's the business's problem either way. They can additionally choose to fire those plumbers if they want, which is line with your point of not believing the plumbers had no idea.

But it's still the company's debt to pay. They made the mistake of hiring people that were not capable of surfacing risks.

[Pamar]

"They made the mistake of hiring people that were not capable of surfacing risks."

Exactly the problem we always deal with: Business tends to distrust Tech because we always seem unable to stay on top of things we build ourselves

[Notanothertoo]

There are two types of tech debt in my experience, things get out of date because they weren't maintained and it's harder to do now years later than absorbing some of that work a little at a time throughout the years. And the other kind is because of poorly written code which is often caused by poor business practices and changing requirements.

[Pamar]

I don't now what your experience is regarding sw development (especially corporate): - in my experience technical debt is often due to:

"There is never enough time to do it right, there is always time to do it twice"