This article more than anything underscores my feeling that there are too many people in programming who should not be doing it in the first place. It&#x27;s a skilled profession, but it&#x27;s increasingly dominated by people who despise the craft aspect of it. This results in both, suckage and bloat on the one end, and unrealistic expectations on the other.<p>&gt; <i>Hiring developers is an extremely difficult task. Learning to program is ridiculously difficult as well.</i><p>If programming was a solved thing, that would mean problem solving itself was a solved thing. It has by nature to be difficult. The question is more whether we manage to avoid additional difficulty on top of that. He&#x27;s talking about the cost of bugs, but I posit the cost of burdensome frameworks and artificial bureaucracies in software development processes is by far bigger and harder to come to terms with, both of which exist in part to manage this inherent difficulty (often achieving the opposite).<p>&gt; <i>Lots of rework happens because of miscommunications with the user. Other times, the user doesn’t fully understand their problem</i><p>This is not unique to software development by any means. Every organization that deals with end users has to negotiate this interface.<p>&gt; <i>anywhere from 50 to 90% of the cost of building software goes towards maintaining it after the first release</i><p>Whether that figure is real depends largely on the type of software you&#x27;re writing. If this fits what you&#x27;re doing, the assumption that at some point the program is supposed to be &quot;done&quot; and every bit of time spent evolving it further must be a sign of inefficiency is simply unproductive. That kind of program is more usefully viewed as an evolving organism, and the sooner management recognizes the nature of this the better it will be handled by the organization.<p>&gt; <i>Our tools don’t make a good separation of essential and accidental complexity[2]––we are forced to crystalize the essential parts of our programs in a programming language and make them coexist with irrelevant, usually platform-specific code (accidental complexity).</i><p>This too depends on the nature of your chosen ecosystem. On the whole, interop has steadily improved throughout the history of computing. We have meaningful universal data formats now, and many options for moving code between platforms. Where interop troubles exist, they mostly exist on purpose (like the iOS example you made). You can absolutely solve most of this problem by throwing computing power at it and choosing an interpreted or cross-compiled environment if you want to avoid writing glue code.