Well Crafted Code, Quality, Speed and Budget
Thank you so much for your detailed reply! That&#x27;s a lot to think about :)<p>Thanks for the hints about defects. I like &quot;unacceptable code&quot;, but it&#x27;s probably still a definition not everyone can live with :)<p>&quot;It&#x27;s Not Much Slower Anyway The Microsoft study on TDD&quot;<p>&quot;You&#x27;re conflating quality and testing here. They&#x27;re not the same.&quot;<p>You are right. My arguments here are only for TDD, and I actually did not want to write a TDD article :) I&#x27;ll think about how to improve that section. Also, CleanRoom is really interesting, but I don&#x27;t know very much about it and never experienced it.<p>&quot;At some point, your users will recognize that it takes longer and longer...&quot;
&quot;Should be one of the top points.&quot;<p>I was thinking about the order of the points a lot, and no particular order seemed <i>really</i> right. It now comes at a point where I think I have established all the preconditions: Speed means lead time, cost depends on speed, high external quality means faster, high internal quality means faster. But you&#x27;re right, the main points I want to bring across come very late in the article. As for the illustrations: Maybe I&#x27;ll write another article about how users care about internal quality - Because I&#x27;ve worked in so many legacy code projects that I think I have a good view on that :)<p>I like your points about the iOS stuff and the short-term jobs. I&#x27;ll think about them some more. I&#x27;m still not sure if I believe the &quot;unlimited downside&quot; idea 100% (because only very few things are truly unlimited), but it&#x27;s an interesting concept.