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