1. Half-done projects started by some happy staff who then went on to start the next project in the next shiny new thing and either more-or-less completed by someone who was just about capable of cut-n-pasting without understanding or who decided that some new shiny thing needed to be added to make the rest wonderful.
2. A monstrous stack of projects in 637 different programming languages, frameworks, ideologies, coding styles, and indentation levels, guaranteed to require rewriting for any change. Result: 638 different things.
I always hear people warn about these things, but haven't seen it in practice at all, as long as those who write the systems are also responsible for operating them and not subjected to inappropriate external interference.
Of course, letting someone write whatever and then move on and leave it to someone else is a problem, but that's a problem regardless of whether they used bleeding edge tech or not.
For example, I've personally seen more tech-debt sins in more traditional monolithic Java + rdbms applications than I have an any of the Go based micro-services + nosql/etc I've seen over the years. I'm not trying to prove that "bleeding edge" is therefore better because it's not. I'm saying it's irrelevant.
The problem of leaving behind unmaintainable crap isn't about the tech, it's about the management, the team processes, the prioritisation process etc.
1. Half-done projects started by some happy staff who then went on to start the next project in the next shiny new thing and either more-or-less completed by someone who was just about capable of cut-n-pasting without understanding or who decided that some new shiny thing needed to be added to make the rest wonderful.
2. A monstrous stack of projects in 637 different programming languages, frameworks, ideologies, coding styles, and indentation levels, guaranteed to require rewriting for any change. Result: 638 different things.