Agreed - nobody is arguing that throwing together sloppy code is always a good thing. Mostly I'm just saying that some amount of sloppy code isn't necessary a bad thing. Like you say, the amount of sloppy code that you can get away with depends on what you are doing.
There are vast discussions about this both online and in books, referring to "sloppy code" as "technical debt". Just like monetary debt, sometimes it is worth taking on a significant debt, while there are other times that it is best to avoid debt. It's a judgement call either way, and I've found that I tend to err on the side of being too scared of technical debt.
Software engineers have an unfortunate tendency to accumulate technical debt and then run away from paying it. I've seen this way, way more often and with far worse overall cost than any kind of perfectionism. The dichotomy between quality and speed of development is often an illusion anyway.
I find it fascinating that elsewhere on this thread somebody expressed the opinion that "overengineering ... kills more projects than anything else" and here you express the opinion that a much worse problem is engineers bailing out after running up technical debt. To be honest, I really can't say which is worse, I've had to cope with both of them from other people. All I can say is that my tendency is to overengineer.
Like I said, I think it's a false dichotomy. Most over-engineered projects I've seen also had ridiculously sloppy code. Over-engineering usually concerns design. Sloppy coding usually concerns implementation. The code at a different stage of development, so it's possible to have both or neither.
I've seen this way, way more often and with far worse overall cost than any kind of perfectionism.
I'm not intending to be some sort of advocate of purportedly bad code, but I find the quoted section to be an interesting statement because, if true (and it likely is true), it simply reinforces the notion that ugly, pragmatic projects endure and succeed: You've seen "way, way more" of that sort because they deliver actual value and end up providing an actual solution for the world, while perfectionists are still busy arguing over trivia.
This is the survivorship bias at play. Organizations accumulate "technical debt" because the only code that gives that any assets has such realistic downsides.
And while you account for the cost, you say absolutely nothing about the benefit/"earnings", which is a typical analysis of people who work on other people's code.
I have created a lot of terrible code in my career, almost always doing greenfield development.
This was code that was spun out under incredible conditions, where we had no idea what our product was going to be, the parameters of the data or the conditions that it would be used in, etc. We had changing dev environments and assumptions, libraries getting tossed and new ones added, etc.
And those projects built companies. And it was always novel hearing someone ranting about technical debt years later, when they were hired in a position and on a team and in a company that only continued to exist because of that solution. Debt indeed.
I've worked with good code and bad code. Where there was good code, programmer turnover was low and the original programmers were still around.
Where there was bad code, turnover was high and the original coders were long gone, the impression I often got was they'd coded themselves into a corner and it was too much for them.
I honestly think places with bad code just have to keep burning out more and more programmers until someone good enough to dig them out of the hole comes along.
The most successful company had the worst code written by incredibly incompetent programmers who didn't even know basic things. One of their products the programmer was so clueless he'd created a new project and DLL for every single class. Every single class. Still made millions.
There are very few coders who can write and design a large product from scratch. Hence far more bad code than good. I think that's the more likely explanation.
Your post has many implied dichotomies and correlations that simply aren't true. For example:
I find the quoted section to be an interesting statement because, if true (and it likely is true), it simply reinforces the notion that ugly, pragmatic projects endure and succeed
Not really. It simply shows that bad software is commonplace and often not important enough factor to kill an entire company. It still costs companies a fortune in maintenance, client dissatisfaction and employee turnover rates.
You've seen "way, way more" of that sort because they deliver actual value and end up providing an actual solution for the world
Uh, again, no. Bad code often begets bad UI, confusing process for the users, botched transactions and a never-ending stream of database tweaks and patches. I've seen plenty of projects whose overall value to the company was negative. Problem is, that negative was spread throughout large period of time, whereas a proper update or replacement of the system would be concentrated in a much shorter time span. This is where "debt" analogy works very well. Some code is like that credit card you maxed out, but only have enough money to do minimum payments.
I have created a lot of terrible code in my career, almost always doing greenfield development.
Whether you created horrible code is largely irrelevant. What's important is what is your overall trend. Some developers pull the code quality up over time, and them maintain it at some reasonable level after that. Others slowly turn anything they touch into radioactive waste.
I'll just leave it at this -- despite protestations to the contrary, I would wager that the majority of developers, if not the overwhelming majority of developers, claim to do no wrong when coding. They claim to plan and design and develop with best practices, creating clean, maintainable code.
And those same developers almost universally declare the majority of code they come in contact with to be toxic waste. Terrible code that brings down companies and kills careers (this whole hilarious discussion began with someone lamenting about the code that Notch burdened Mojang with. The code that is the sole reason for that company existing. What a horrible burden).
These claims do not mesh. At all. There is a reality that is profoundly different from what people say.
This reminds me of how some people argue that morality is hard, because everything is relative, while doing thing they themselves clearly do not consider "right".
Aside from a few inexperienced or delusional engineers, most people I've seen in my professional life are cognizant of the quality of code they produce. The main difference is in how they respond to the cases when that quality dips below a certain level.
There are vast discussions about this both online and in books, referring to "sloppy code" as "technical debt". Just like monetary debt, sometimes it is worth taking on a significant debt, while there are other times that it is best to avoid debt. It's a judgement call either way, and I've found that I tend to err on the side of being too scared of technical debt.