"
Thank you so much for your detailed reply! That's a lot to think about :)"

You've very welcome. :)

"Thanks for the hints about defects. I like "unacceptable code", but it's probably still a definition not everyone can live with :)"

I kind of came up with it off the top of my head. Point is that the code will be rejected on relatively arbitrary criteria. It might be known defects, coding style, what libraries were used... anything. Hard to find a word or phrase covering all that which people will agree with.

"Also, CleanRoom is really interesting, but I don't know very much about it and never experienced it."

This presentation...

http://groups.engin.umd.umich.edu/CIS/course.des/cis376/ppt/...

...summarizes it for you in about 5 min of reading. The first attempts to make software in a scientific way, engineered software I call it, were done by Margaret Hamilton (founder of our field) at NASA plus academics like Dijkstra and Hoare. They all produced nearly defect-free systems in a systematic, often mathematical way. Harlan Mills took the lessons to industry when developing Cleanroom: a combo of lightweight formal methods, design constraints, spec/code verification, incremental development, and usage-driven testing. He wanted SW products to be as low-defect as HW clean rooms. Result was code at extremely low defect rate that was consistent enough for statistical certification. While popular, Cleanroom teams actually warrantied their software.

Altran/Praxis is another company I know that (a) truly engineers software and (b) warranties it at specific defect rates. Defect rates are usually better than the Linux kernel and close to the Space Shuttle's control code. Here's a case study of their Correct by Construction process applied to high-assurance, certificate authority:

http://www.anthonyhall.org/c_by_c_secure_system.pdf

So, there's you two methods that already maxed out quality (and/or security) on real-world projects. Altran charges an acceptable premium for quality but Cleanroom often cost nothing extra or saved money for same reasons as you article says. Appears the modern programmers still have lessons to learn in software quality from the 1980's. Like I tell people, the old wisdom is often pretty solid even after you fix outdated parts. Our field is just terrible at passing it down. I try to fix that with posts like this so the smart, young people get a boost toward whatever great things they create. Also reduce endless rediscovering of fire and reinventing the wheel. :)

"I was thinking about the order of the points a lot, and no particular order seemed really right. It now comes at a point where I think I have established all the preconditions: Speed means lead time, cost depends on speed, high external quality means faster, high internal quality means faster. "

I'm going to let you keep working on that formula. You've got the right ingredients. Far as order, there might not be any. Many things in engineering or business are holistic where the parts all feed into each other. The goal is an emergent property of that. So, rather than an order, you'd visualize it like a bubble chart or something that with connections between the components and labels for the effect they have. Just something that's clear that they're all connected, all feed into each other, and ignoring one breaks the process for achieving the goal. Just my dos centimos.

"Maybe I'll write another article about how users care about internal quality - Because I've worked in so many legacy code projects that I think I have a good view on that :)"

You should. Matter of fact, you should do a lot more work on figuring out how to measure and convey the importance of eliminating technical debt. To laypersons, not geeks. Not enough work here despite its importance. Everyone is instead making arguments for geeks that already get it cuz they're knee deep in the crap or picked the job that didn't have it.

Great attempt here:

http://tech.ticketmaster.com/2015/06/30/what-ticketmaster-is...

Tool for metrics here that was interesting. Not tried it, though.

http://swreflections.blogspot.com/2012/02/technical-debt-how...

" I'm still not sure if I believe the "unlimited downside" idea 100% (because only very few things are truly unlimited), but it's an interesting concept."

I just thought it sounded catchy. Not committing to it myself. ;)