Excellent breakdown of the issues. I can see the references on the site countering many of those problems. Your bridge analogy reminded me of this article that came up here around the same time:<p><a href="http:&#x2F;&#x2F;www.dev9.com&#x2F;article&#x2F;2015&#x2F;1&#x2F;the-myth-of-developer-productivity" rel="nofollow">http:&#x2F;&#x2F;www.dev9.com&#x2F;article&#x2F;2015&#x2F;1&#x2F;the-myth-of-developer-pro...</a><p>Considering making it my current reference for explaining this stuff to managers I meet in a short time and with a quick link. I also agree the software crisis largely came from the cheaper <i>unit prices</i> of hardware, complexity exploding in software to take advantage of it, and many management issues. Also inspired Wirth&#x27;s Law where he made the same observation while trying to avoid it himself.<p>Only inaccuracies I see are these:<p>&quot;When programming is being done effectively, you automate all the repetitive parts, which dramatically reduces costs and timeframe, but dramatically inflates the unpredictability.&quot;<p>It doesn&#x27;t just do that. The 4GL&#x27;s, the <i>good</i> ones, did that with great productivity benefits in the common case and ability to call custom code for the rest. Many programming aids do today, too. So do the languages offering good macros. However, the methods I advocate here do more than that: support designer&#x27;s understanding of what system does; find high-level issues in requirements or specs; find interface errors (critical); prevent all kinds of things by construction; detect others; enable easier portability with native efficiency; ensure executing code matches source. Just a few recent examples and with each requiring human effort. No amount of programmer skill in C with ad hoc requirements&#x2F;design techniques replicates these without considerably more effort or the most experienced, elite programmers.<p>So, the tactics and tools from Comp Sci + High assurance&#x2F;integrity field certainly have value beyond automating tedium. These also tend to <i>increase</i> predictability once people are used to them because they reduce risk and the debugging that follows. The trick is to choose just the right ones that boost the developer&#x27;s abilities without bogging them down. I don&#x27;t have a single recommendation there as (a) one must use best tools for the problem and (b) they experiment too damn much in Comp Sci to the point that I can&#x27;t say whats better for <i>most</i> methods or tools. Only what&#x27;s worked and for what. So, the specifics I bring up change depending on topic &amp; audience. Eventually, we&#x27;ll see some convergence with more uptake. Like how Amazon&#x27;s using TLA specifications now with results I predicted when encouraging that sort of thing for years.<p>&quot; The &quot;crisis&quot; is that it costs literally a million times more to write the code than it does to make the processor. &quot;<p>Here I believe your overall point is hardware, unit cost vs developer cost along with what leads to. I agree with that. Just wanting to make sure you know that line isn&#x27;t true in general as many programmers think it is. Hardware development is <i>expensive</i>, esp CPU&#x27;s. I&#x27;ve been pushing on Schneier&#x27;s blog and elsewhere a number of CPU modifications that eliminate entire classes of errors (eg code injection, leaks). Most of them have prototypes to draw on or are specific enough for opencores crowd to handle. Yet, you see almost no attempts to put them into an ASIC even when people know about it. That goes for opencores stuff, too, for most part. That&#x27;s because hardware development is ridiculously expensive even for adding a block or two to a RISC CPU with prototypes.<p>The reason is mainly the mask costs, tooling, and labor. The masks, which are necessary for printing chips, for 350nm-180nm (minimum useful) are $100+k per design test. Wafer and packaging might be $5-10k. Every screw-up requiring a change means new masks and maybe 4 months waiting. You minimum staff of 3-5 pros, as rookies make too many mistakes, will set you back same amount if not Asian and with tools that start around $50k a seat <i>on low end</i>. For hardware that&#x27;s smaller or faster, all those variables go up dramatically with tools for deep submicron (esp synthesis) runnning $1+ mil a seat plus needing four or five different tools. Sometimes more than 10 on most advanced nodes. Your CPU was probably made on a node where one prototyping run (think unit test) of your HDL code cost $1+ million dollars.<p>There&#x27;s tricks to keep costs down, mostly software-inspired as you guessed. Adapteva probably the best at it using pre-proven I.P., simplicity in custom stuff, re-use of it in future iterations, HW&#x27;s version of structured programming, cheapest tools, utter pro&#x27;s for team, and customers willing to pay significant, unit prices. Still cost them $2 million. Most SOC&#x27;s costing $15-50 mil. I managed to come up with flows, open and proprietary EDA, for anti-subversion of open, secure hardware. Found shortcuts like S-ASIC&#x27;s (eg eASIC, Triad) got it down to like $400,000 but with volume requirements. Still high. RISC-V Rocket processor, etc are happening because academics get paid in grants, get EDA tools for low five digits, and get discounts on ASIC prototypes. They&#x27;re our best hope for OSS, secure chips. But I hope I&#x27;ve illustrated HW is in no way cheaper than software except in unit price of something where demand spreads out development costs to make it low.<p>Note: Microcontrollers you cite are a special case not like the rest. Developed by pro&#x27;s, very limited functions, cheap tools, much reuse, on fully-depreciated fabs often owned by the vendors that reduce itereation costs, and in such ridiculous volume that further reduce costs. Even the cheapest fabs with your tiniest design will charge you $3,000+ for the minimum order. When has a compile-and-test cost you that much? ;)<p>With that foundation laid, I can then say your CPU is going to cost way more than the software. Especially if it&#x27;s Intel, AMD, or IBM: full-custom for top performance, power efficiency, density. That requires more of the best engineers, more time, and more masks ($1+mil per set) on the best nodes. The inevitable logic screwups and their respin cost require extra tooling, both commercial EDA and custom, to counter the problems: Intel uses formal verification [1], IBM mostly falsification [2]. I&#x27;m not sure what your CPU cost vs the software on it as numbers are hard to come by. I do know that Solaris 10, a whole UNIX rewrite, cost around $200-300 million while the Cell processor cost IBM $2 <i>billion</i> to develop. Intel spends $10.6 billion a year on their product lines with most on hardware end. So, Standard Cell hardware is more expensive than software with full-custom plus high-end specs being insanely expensive.<p>So, it&#x27;s probably best for that old meme to die since the world has changed and shit much more expensive now. Your points about effects of unit price vs developer cost still stand and all. I just wanted to make sure you knew just how hard hardware was today &amp; at what prices. Plus, there&#x27;s always the tiny chance that a smart guy like you reading these posts will say &quot;Challenge Accepted!,&quot; then build a secure, surprisingly-fast processor for us on an older node. :)<p>Note: +1 for the reference to Engelbart. His videos prophetically talking about (and illustrating) remote collaboration, etc were some of the most visionary things I&#x27;ve ever watched from the field&#x27;s history. Mind-altering to look back at them trying to look forward and getting a lot right for the time period. Very specific stuff, too.<p>&quot; No, anybody can learn how to program. &quot;<p>VERY TRUE! I try to remind everyone that doubts it. More tools and ease of use today than ever to get started at whatever level they&#x27;re comfortable with. Worst case, they think it&#x27;s too hard, say that yes they played with Legos, I hand them Scratch [3], and they on the way to programming haha. The basics are really as easy as breaking things down into steps and building them like Legos. A kid can do it... :)<p>[1] <a href="https:&#x2F;&#x2F;www.cl.cam.ac.uk&#x2F;~jrh13&#x2F;slides&#x2F;nasa-14apr10&#x2F;slides.pdf" rel="nofollow">https:&#x2F;&#x2F;www.cl.cam.ac.uk&#x2F;~jrh13&#x2F;slides&#x2F;nasa-14apr10&#x2F;slides.p...</a><p>[2] <a href="http:&#x2F;&#x2F;fm.csl.sri.com&#x2F;SSFT11&#x2F;FV_Summer_School2011__HW_Verif.pdf" rel="nofollow">http:&#x2F;&#x2F;fm.csl.sri.com&#x2F;SSFT11&#x2F;FV_Summer_School2011__HW_Verif....</a><p>[3] <a href="https:&#x2F;&#x2F;scratch.mit.edu&#x2F;" rel="nofollow">https:&#x2F;&#x2F;scratch.mit.edu&#x2F;</a>