Test-Driven Development is Stupid
There have been one or two HN posts somewhat recently indicate that developers should stop calling themselves &quot;engineers.&quot; Enter examples of how engineered solutions generally work the first time round, and how software almost universally does not. There&#x27;s a fundamental reason for that: it&#x27;s computer <i>science.</i><p>One of the facets of science is that you have a hypothesis. Writing a unit test before you start is analogous to having the hypothesis: &quot;the solution I come up with for this problem will work.&quot; The rest of the exercise of TDD is a scientific process of creating a solution and <i>proving</i> that your solution works (and adjusting your hypothesis if you find it to be incorrect), albeit in a slightly strange way.<p>I could have a hypothesis about how earth is really traveling through the stars on the back of a turtle. We know that is not true because Einstein came up with a solution, followed by him and others <i>proving</i> that solution. Relatively is only valuable because <i>proof</i> of it exists.<p>If computer science is a science (which it is) we must put our solutions to the same degree of rigor that other scientists do.<p>While I no longer follow the strictest form of TDD (starting with tests that fail to compile) I&#x27;ll never forget the singular most important lesson that it has taught me:<p><pre><code>    A solution is worthless if you cannot prove that it works.
</code></pre>
I&#x27;d take this article more seriously if Mr. Mallett provided an alternative for correctness proofing. I can&#x27;t honestly sell software to someone if I don&#x27;t know if it works myself.