> Literally every book on project management

The real world is much sloppier than any book will ever tell you.

> is about the development cost vs maintenance cost

Absolutely true.

> how the latter beats the former

If you're believing that equivocally ((I don't think you personally are btw) then I don't think you're reading the advice the book is giving you correctly.

A shitty technical solution that gets to market quicker often (not always) can make the company more money in the long run. There is no "one right answer" here, it's all about judgement. 100+ tech DD's and counting...I've seen the whole spectrum. I've seen a $40M revenue (38% EBITDA) tech company built using a FileMaker-like tech stack (all WYSIWYG). And yes, I'm serious.

The key word here is "solution." If your code is supposed to do a job, and for whatever reason it's not doing that job, then you do not have a solution.

Code that doesn't do the job is worthless, no matter how testable and well-designed it is.

Of course you can debate whether this is a management (scheduling, resource, PM) problem or a developer (competence, architecture, tool choice) problem - most likely some of both.

But whoever is responsible, it's still a non-solution.

Because what a "10x developer" (i would just call them pragmatic, personally) might call a shitty solution is still better than what you may call a well designed testable solution?

Not everything needs 90% test coverage and more comments than code to be good. And not everything with 90% test coverage and more comments than code is any good at all.

Not at all. The quality of the code may be terrible.

BUT - when someone else new comes along to look at it, the 90% code coverage, and comments helps them immensely - they can get up to speed to fix whatever bug has appeared a lot quicker.

This is so true, because people that are really good at something usually hold themselves to incredibly high standards (which is one of the main reasons they become master craftsmen in the first place).

Yes. The standard is so high that they can't even find words for it. So they just call it simply shitty.

Pragmatism based on shittyism? Or how shall we imagine this? Is there a motto for this? "We excel in shitty code or something?"

I think you are missing the point. That someone calls their own solution "shitty" doesn't mean that it's shitty by your standards, its shitty by theirs. The reality is that people have different standards. I don't understand the hate you seem to be exuding for productive people.

I think it's just another variant of Less is More