That's probably the appropriate way to tackle new projects, you know. Most ideas suck. Therefore the first (few) versions of such software is perfectly reasonable if it's rushed.

I hate that I work at a big company and we get into new project discovery mode and then take 3-5 weeks to code up extremely over complicated prototype programs. But they have tests (usually more than code), they have "good design", they have code that's reviewed and sent back at least thrice, they're stable, they've got monitoring, ... And they take huge amounts of time.

The one quality all of that has is that everybody agrees it's a good idea. When trying to quantify what that means ... I completely fail.

The design always fails to account for something. I have had it happen once that the initial design actually lasted to "v1.0", in 3 years. So I'm becoming unsure what makes a design good, except everyone agreeing that it's good and a certain "clean" look there is no difference between a good and bad, clean and messy, thought through and ad-hoc. Good designs don't survive a few feature iterations any better than bad designs, but they impose lots of extra costs on feature iterations. And that's assuming people don't make the mistake that turns the best of good designs into horrible designs : sticking to it. Attempting to fit new features into a design that didn't account for them can make the most beautiful design an utter disaster.

Same thing about reviews. Reviews seem to make people make huge changes in one go, because that feels much better if people regularly argue about much of it, compared to having to redo a change that by the time it's reviewed 5 other things depend on, where you get to throw out the 5 other things. And of course fairly commenting on huge changes is not done because pretty soon you'll feel guilty about the amount of work you're causing. Which is exactly why people have a better experience making huge changes, of course.

Tests ... never prevent bugs. Now I'm not saying tests don't have value, but the current testing culture is utterly and completely broken. I've simply decided to hack the system : a cli to your methods that allow you to quickly do ad-hoc tests and record them into generated code. Why ? First, it allows you to test against real-world data, which means your idea of what your code does actually meets real world data instead of artificial cases that may miss the point in the same way your code does. Second it allows you to quickly regenerate the tests if there is some big change needed. And thirdly it completely hacks the system. Getting coverage is trivial. And your LOC stats will be through the roof. Double bonus if you do this for less-than-expressive languages like C and Go, it's less necessary for things like Java and C++.

But "best practices" seem to make everyone happy in big companies, make everything take very long, and because of that very often cause the failure they're trying to prevent. It's like in chess : people like "safe" moves once you've beaten them once or twice. And in 10 moves or so they get themselves into a situation where they have to give up that safety, and your "haphazard" moves turns out control 80% of the board and fighting from that situation is not going to go well. But it's the desire for safety, the fear of loss, that's exactly what's causing their loss. They don't see things this way, though. If only they'd moved this piece to cover that as well, then it would have been fine. It doesn't even seem to matter if you show them that no, it wouldn't have been fine. That the issue was their attempt at securing what they did resulted in a complete takeover by the other party.

And every attempt I make at changing this fails, often with people having emotional breakdowns and complaints. And then their projects fail, again and again. Multiple times people have been very angry at me for providing a solution to some problem they were doing a 2 year project, restarted from scratch 3 times, for by writing a 300 line script that utterly kills interest in their project because it works and solves the problem. Apparently that "violates trust".

I don't understand why businesses want this. It keeps the peace, yes, practices like this, at the cost of efficiency, at the cost of developer sanity (developers wash out after about 5 years despite the current employment conditions, and often become non-developers. Hell, several people I know became accountants and prefer it over software development. Seriously).

And despite this, people seem to further down the rabbit hole every time I seem to look at it. WTF ?