I feel like the fear of technical debt is driving organizations to make rash decisions. I think we’re creating more technical debt by rushing to replace perfectly working and supportable systems with clobbered together ones using the framework of the week. Maybe I’m just old though too. I don’t know, I think I’m just getting tired of re-writing the same system over and over again.

Tech debt is not changings things that work. It is about "how much overhead is there when adding a new feature".
If you are rewriting things just to rewrite them....

I hear you and I understand and agree.

But, if tech debt is actually obstructing the company to attract competent people then it is paramount to actually do something about it.

And if you do not attract people who actually know something then you are on a slippery slope to a situation where everybody who knows anything about software engineering will leave the company because they feel that they do not have a stimulating work place.

@magicMirror well put. And that’s my concern. For example, I’m on a team that is rewriting a series of apps that are written in a popular, well supported language into another popular well supported language. It’s not even a company initiative to do this, and has now doubled our support work since we have our application platforms essentially duplicated during this multi-year transition. I’m having a hard time with it.

@sideshowbob76 Absolutely, if support is an issue, then we have to replace the system.

@fiftyhz Creating tech debt!

@magicMirror Hahaha, very true!

They're always rushing. It's not new. 🥲

The rushing, cut corners, dev incompetence, ignoring of devs, etc is why companies are in this mess - it's always been there and it's everywhere unfortunately.

Learning to live in it, and tame high value areas to bring stability are the only ways to survive apart from calling quits.

Oh and complete rewrites almost always fail apparently

Mobbing, active dev "craftsmanship" improvements, automated testing, and self organising teams have helped us.
'Improvement of work over daily work itself' + agile principles.
That and having people who can speak corporate for devs as most of us didn't become programmers to manage and handle stroppy business people