To get great software, you need a small team and give them extremely clear requirements of what it should do with an assload of extremely clear testcases.
And lots of time to tune things and solve all little problems, and manually implement things when abstractions hamper performance.
This is a fairly generalizable rule in any engineering, unless you really are running the Apollo program (then when divide-and-conquering should probably remember this rule).
This is running into the no-code problem of clear-enough requirements being as complex as the code, via Kolmogorov.
The best software comes from a small team of top level devs who are also top level subject matter experts on the software’s domain. This doesn’t happen very often.
It doesn't have to be a small team. See "They Write The Right Stuff".
And even they make mistakes, software contains much more moving parts than hardware.
> Use of pointers required a written, approved, variance from the SW standards board. All the code was formally peer reviewed by at least 6 people. More complicated code would be reviewed by 20+ people - in the same room.