TDD did not live up to expectations
TDD failed for economic reasons, not engineering ones.<p>If you look at who were the early TDD proponents, virtually all of them were consultants who were called in to fix failing enterprise projects.  When you&#x27;re in this situation, the requirements are known.  You have a single client, so you can largely do what the contract says you&#x27;ll deliver and expect to get paid, and the previous failing team has already unearthed many of the &quot;hidden&quot; requirements that management didn&#x27;t consider.  So you&#x27;ve got a solid spec, which you can translate into tests, which you can use to write loosely-coupled, testable code.<p>This is not how most of the money is made in the software industry.<p>Software, as an industry, generally profits the most when it can identify an existing need that is currently solved without computers, and then make it 10x+ more efficient by applying computers.  In this situation, the software doesn&#x27;t need to be bug-free, it doesn&#x27;t need to do everything, it just needs to work better than a human can.  The requirements are usually ambiguous: you&#x27;re sacrificing some portion of the capability of a human in exchange for making the important part orders of magnitude cheaper, and it&#x27;s crucial to find out what the important part is and what you can sacrifice.  And time-to-market is critical: you might get a million-times speedup over a human doing the job, but the next company that comes along will be lucky to get 50% on you, so they face much more of an adoption battle.<p>Under these conditions, TDD just slows you down.  You don&#x27;t even know what the requirements are, and a large portion of why you&#x27;re building the product is to find out what they are.  Slow down the initial MVP by a factor of 2 and somebody will beat you to it.<p>And so economically, the only companies to survive are those that have built a steaming hunk of shit, and that&#x27;s why consultants like the inventors of TDD have a business model.  They can make some money cleaning up the messes in certain business sectors where reliability is important, but most companies would rather keep their steaming piles of shit and hire developers to maintain them.<p>Interestingly, if you read Carlota Perez, she posits that the adoption of any new core technology is divided into two phases: the &quot;installation&quot; phase, where the technology spreads rapidly throughout society and replaces existing means of production, and the &quot;deployment&quot; phase, where the technology has already been adapted by everyone and the focus is on making it maximally useful for customers, with a war or financial crisis in-between.  In the installation phase, Worse is Better [1] rules, time-to-market is crucial, financial capital dominates production capital, and successive waves of new businesses are overcome by startups.  In the deployment phase, regulations are adopted, labor organizes, production capital reigns over financial capital, safety standards win over time-to-market, and few new businesses can enter the market.  It&#x27;s very likely that when software enters the deployment phase, we&#x27;ll see a lot more interest in &quot;forgotten&quot; practices like security, TDD, provably-correct software, and basically anything that increases reliability &amp; security at the expense of time to market.<p>[1] <a href="https:&#x2F;&#x2F;dreamsongs.com&#x2F;RiseOfWorseIsBetter.html" rel="nofollow">https:&#x2F;&#x2F;dreamsongs.com&#x2F;RiseOfWorseIsBetter.html</a>