<story><title>Sensible Software Engineering</title><url>https://www.scriptcrafty.com/2019/02/sensible-software-engineering/</url></story><parent_chain><item><author>wildmanx</author><text>&amp;gt; Bugs are correlated with lines of code and TDD forces writing more code so how can it reduce bug counts? If the test code has no bugs then just write the rest of the code in the same style&lt;p&gt;Nobody has pointed out the fault in this reasoning yet, so I will.&lt;p&gt;The linear relationship lines-of-code vs. total-bug-count is based on independence of bug introduction in different parts of the code. That is, introducing a bug in line 10000 is more-or-less independent of adding line 20000. For product code that is arguably the case, but adding test code into the mix, this basic assumption doesn&amp;#x27;t just not hold, but it&amp;#x27;s turned upside down.&lt;p&gt;Test code is not customer-visible, but only dev-visible, with the sole purpose of finding bugs. Thus, adding test code to a code base &lt;i&gt;decreases&lt;/i&gt; the average probability of a bug for lines of product code. More formally, if you have N lines of product code and thus c * N bugs for some fraction c, then adding M lines of test code does &lt;i&gt;not&lt;/i&gt; increase the number of customer-visible bugs to c * (N + M). Instead, it reduces that number to c&amp;#x27; * N with c&amp;#x27;&amp;lt;c and the difference being caused by your test coverage. (A 100% test coverage, i.e., an exhaustive test without bugs or, equivalently, a formal verification, would bring c&amp;#x27; to 0.) Sure, the M lines of test code may well have bugs on their own, but that only increases c&amp;#x27; slightly while keeping it below c, and more importantly, those test bugs are not customer-visible. They only annoy developers.&lt;p&gt;I agree with the rest of the post though.</text></item></parent_chain><comment><author>ericathegreat</author><text>Agree. Consider the situation of data entry professionals, those people who transcribe audio recordings or enter data into databases.&lt;p&gt;If you have one person entering data into a computer, then the odds of them introducing an error and failing to spot it are fairly high.&lt;p&gt;If you have twice as many people entering twice as much data data, then the odds of an error getting introduced are roughly doubled.&lt;p&gt;However, if you have those two people entering &lt;i&gt;the same&lt;/i&gt; data, then their mistakes cancel each other out. If person A and person B both entered the same thing, it&amp;#x27;s extremely unlikely that it&amp;#x27;s incorrect. If they differ though, the a problem has been identified, and can now be fixed.&lt;p&gt;The odds of both of those people entering the same piece of data incorrectly is tiny. Likewise, &lt;i&gt;accidentally&lt;/i&gt; introducing a bug into both the production code &lt;i&gt;and&lt;/i&gt; the test is pretty unlikely.&lt;p&gt;That said though, if those two theoretical data entry people above are given the wrong data to enter, then they the system cannot protect them. They will both correctly enter incorrect data. &amp;quot;Garbage in, garbage out&amp;quot;.&lt;p&gt;Likewise, if the requirements of a piece of software are poorly understood, then it is quite likely that both the test and the production code will implement the same &amp;quot;bug&amp;quot;. Writing tests won&amp;#x27;t fix a failure to understand the problem you&amp;#x27;re trying to solve. And they&amp;#x27;re not supposed to.</text></comment>
<story><title>Sensible Software Engineering</title><url>https://www.scriptcrafty.com/2019/02/sensible-software-engineering/</url></story><parent_chain><item><author>wildmanx</author><text>&amp;gt; Bugs are correlated with lines of code and TDD forces writing more code so how can it reduce bug counts? If the test code has no bugs then just write the rest of the code in the same style&lt;p&gt;Nobody has pointed out the fault in this reasoning yet, so I will.&lt;p&gt;The linear relationship lines-of-code vs. total-bug-count is based on independence of bug introduction in different parts of the code. That is, introducing a bug in line 10000 is more-or-less independent of adding line 20000. For product code that is arguably the case, but adding test code into the mix, this basic assumption doesn&amp;#x27;t just not hold, but it&amp;#x27;s turned upside down.&lt;p&gt;Test code is not customer-visible, but only dev-visible, with the sole purpose of finding bugs. Thus, adding test code to a code base &lt;i&gt;decreases&lt;/i&gt; the average probability of a bug for lines of product code. More formally, if you have N lines of product code and thus c * N bugs for some fraction c, then adding M lines of test code does &lt;i&gt;not&lt;/i&gt; increase the number of customer-visible bugs to c * (N + M). Instead, it reduces that number to c&amp;#x27; * N with c&amp;#x27;&amp;lt;c and the difference being caused by your test coverage. (A 100% test coverage, i.e., an exhaustive test without bugs or, equivalently, a formal verification, would bring c&amp;#x27; to 0.) Sure, the M lines of test code may well have bugs on their own, but that only increases c&amp;#x27; slightly while keeping it below c, and more importantly, those test bugs are not customer-visible. They only annoy developers.&lt;p&gt;I agree with the rest of the post though.</text></item></parent_chain><comment><author>sombremesa</author><text>Tests don&amp;#x27;t exist for solving bugs as much as they exist to prevent regression. Writing exhaustive tests is not sufficient to bring c&amp;#x27; to zero, because some of those bugs exist because of the developer&amp;#x27;s own presumptions about how code should behave.</text></comment>