&quot;The study likely assumed that people already familiar with working in these methodologies were equally available, equally happy to do so, and equally priced as regular developers, which is unlikely to be case.&quot;<p>For things like Cleanroom and PSP&#x2F;TSP, they were first-time users of the process. Not long-time. Just decent developers shown a better way of getting results. In high assurance, it varied from first-time to experienced users. First time users usually gained the benefits of the method but with difficulty. There&#x27;d be at least one specialist aiding the team. Best results came from people who had done it a while. So, for high that&#x27;s partially true and for stuff I push on commercial sector it&#x27;s the opposite.<p>&quot;A certain minimum team size is probably required to make many of these processes viable; many real world systems are written by solo coders. &quot;<p>That&#x27;s a legit critique. They can still benefit as I experienced myself and some others. It requires one to divide the work into periods where you wear various hats. It takes discipline to externalize one&#x27;s own work and attack it objectively. Good news is that inspection, testing, static analysis, model-checking, design-by-contract... these all catch problems that are objective more than subjective. Still get plenty of results. There&#x27;s been one or two threads on here where even solo people do QA on their own stuff with good results.<p>Still open-ended problem worth some experiments to see how much can be done at what effectiveness for a solo coder juggling work. So, good point.<p>&quot;in reality it is relatively trivial to scavenge &quot;<p>It&#x27;s so trivial we had today yet another HN thread about distributed locks showing how people were copying one implementation and screwing it up. Then there was disagreement in the comments. There&#x27;s threads like that on various critical things at least once a day or so on HN. Shows it&#x27;s trivial to do and hard to do right for many things. Better to make re-usable, strong solutions to the various problems we keep encountering where possible. Can always mix high, medium, and average assurance components as a compromise where we have X goals but only Y resources. Pieces can improve over time.<p>&quot;Indeed, the implementation of such is becoming near free many cases due to convergence on SoA&#x2F;microservices.&quot;<p>I&#x27;ve yet to see one go 5 years under heavy load without downtime much less the 17 years VMS clusters did or 30+ years for some IBM mainframe installations. For security, things are more abysmal. I&#x27;ll agree many solutions are popping up that can do amazing things. Robust, scalable, fairly secure, and near-zero-downtime systems don&#x27;t seem to be among them in this nearly-free, mainstream market you&#x27;re talking about. A rarity in the market in general.<p>So, there&#x27;s still room for both medium and high assurance software. To be clear, I&#x27;m only pushing medium because even first-timers did a better job than most do today by eliminating the problem areas &amp; doing great detection. Similar cost, too. Only <i>hoping</i> for high-assurance to be selectively applied to high-impact stuff that doesn&#x27;t change often. A recent example was a formal verification of SCOOP: Eiffel&#x27;s race-free, easy-to-analyze, concurrency model. It found issues in the model that were fixed. Three other analysis, ranging from specific to general, eliminated deadlocks, livelocks, and performance-hit respectively. That&#x27;s the kind of situation where a significant investment of resources can keep providing benefits with almost no effort. Otherwise, medium assurance aka commercial + sane extras.<p>&quot;&quot;I can get another if I break it, so a clay cup trumps a grail.&quot;&quot;<p>Nice quote and good principle in much of current economy. Not so much my personal data or business I.P. when a byzantine failure takes out it and my hot standby. I think the comparison mainly applies to non-critical services and hardware. ;)