It’s awful.
It also doesn’t help that “minimum viable” is only one step away from “non-viable”. Every project then becomes like Icarus, testing how close to the sun we can fly before our wings melt.
The absolute greatest wastes of talent and humanity I've ever seen in tech didn't come from tech debt, those efforts were almost always at least working on a product that people were paying money for. The biggest wastes were from over-delivering products that hadn't and were never going to succeed.
The world we have now where everything is built to be thrown away, including software, has had the side-effect of destroying craftsmanship. And I'm becoming more convinced as I age that the world is poorer for it.
Not every area in the software market is like this. For example, in ERP software often applications from the 90ies are still in use (maybe revamped, maybe not) by many customers. And the maintenance periods are measured in decades (typically not initially, but there always seems to be a maintenance extension).
If you make an MVP and end up discarding it shortly after, that’s fine, and completely appropriate for an MVP.
OTOH, MVP may not be sufficient for something that the business still relies on day in, day out months or years down the road.
That's why I love ELM as a front-end langauge (and hope to see a successor ROC succeed).
For back-end, that's why I love Rust, Haskell etc. All languages that are closer to Pure, FP. Because I can leave codebase to other devs and still know that it's not gonna turn into something which I've seen happening to Python, PHP and other OOP language codebases.
I once had a client who'd had a shiny but disorganized MVP developed on .NET, and of course as the org tried to scale and ramp up new features, the devs had to fight more and more against the design (or lack of it in some parts, or overly complex over-design in other parts). At some point he met some dude at a networking event who had built a successful business on a Node codebase, and became convinced that we should rewrite from the ground up in Node because our performance problems were all the platform's fault. Wrong wrong wrong. But it's much easier to believe a sales pitch than to do the hard work of learning what good, performant design in your chosen language/framework looks like.
Some languages make refactoring easier and some make it harder. FP languages make it easier
You can make bad things in any language. I like Go for the same reasons you like FP. And there too, people can do strange and unmaintainable things
And not going for the shiny things do not fit!
Because limitations are everywhere. Ok, software engineers like to pride themselves in the ability to do anything and everything (not as much as salesguys of course) but this stems from the ninja attitude towards technology and forgetting other dimensions of reality. Should only attempt managable goals on all necessary levels.
I am still waiting for place where this is achieved...
You can still get teams who are scared of what they own and refused to update it, but that is a whole lot of "and so? Do it" when you have a healthy product backlog that is single stack priority and the higher priority thing requires output from them (while a pain, it didn't happen _that_ often).
To be fair, $prev_gig was a very well ran company in a lot of ways and better than any other shop I have been in.
[1]: https://store.steampowered.com/app/246900/Viscera_Cleanup_De...
In fact, one could wager that the situation you described is directly a consequence of not adhering to what OP is suggesting.
It's one of those interesting and infuriating things. There's a category of PHB managers who can't code, can't design, can't inspire, can't really do marketing well at all. They're marginally more skilled and way less funny than Michael Scott.
Their advantage is being unencumbered by knowledge. They don't suffer the technical decision-making process. They don't try to compete on the value-added charts. By not really caring, they sail through dotting the i's and just forget about the t's. The product ships with a hundred blemishes and two major flaws. It was rushed out the door by the asshole with the padded resume and the HR surfing history.
They abused the flaws in the system to subvert the meritocratic outcome. From their perspective, they did what they had to do to "win."
The residual team was left to clean up their code and make it work, which often involved significant rework.
I raised my concerns with management that they were cheating their "rock star" dev out of valuable learning experiences and perpetuating the problem - the dev made the same errors on each new project. Not to mention, perpetuating their testing nightmares.
> The difference between the 10x dev and 1x dev is that the former creates bugs 10x fasterI've been there and i've inherited some stuff to manage, and it's painful.
But there's another side of this, which is even more painful and definitely infuriating: some people get to stay on the same project for years, and they become "key people" just because they've either A) stumbled on the issues before or B) have introduced the issues themselves.
This is completely infuriating because now you have to play cat and mouse with these people to get help, and they get to play the "super busy, everybody ask me stuff" role because they're the only people with that historic knowledge.
Needless to say, they can also back the claim they deserve a promotion (and a salary increase) by executing on.this playbook. And they usually do.
I've seen this thing happen in pretty much all company sizes (200 people, 1000 people, 500k+ people).
At this point, after almost ten years in the industry, I'm starting to think this is the winning playbook for the meta-game: go rogue in a maliciously-compliant way, artificially claim superiority over your peers, get promoted.