Is Uncle Bob serious?
Background. When I first heard of Uncle Bob, I watched a couple of conference videos.<p>Man, the guy pissed me off. He seemed quite strident in this &quot;software craftmanship&quot; schtick.<p>As it turns out, I had written an article on all the horrible ways companies implement Agile. It&#x27;s gotten to the point that I cringe whenever I hear the word &quot;Agile&quot;, and I consider myself an Agile Technical Coach. Orgs just really suck at trying to do better. Most of the time it ends up in a micromanagement death march.<p>Bob read this. It pissed him off.<p>So Bob and I met online by pissing one another off. We commented on each other&#x27;s works, and over the years, we&#x27;ve become friends. So I speak both as a coder, a consumer, friend, and a fellow talking head.<p>Bob means well, but with a large audience people tend to read into his work things that aren&#x27;t there. This is the HN effect: with a large enough audience nothing you say or write will be immune from misunderstanding. He also tends to overstate his case from time-to-time, like we all do. Hyperbole is a useful rhetorical tool.<p>I restate his thesis in my own words as such: <i>The number one problem in software today is hidden complexity, mutability, and state. When programmers enter a new domain, they naturally tend to &quot;help&quot; follow-on programmers by creating abstractions on top of whatever complexity they find. This increases, rather than decreases the hidden-state-mutability-complexity problem.</i> It gives the appearance of being useful, but in fact can do more harm than good. Focusing on the tools instead of doing a good job gives this wonderful rosy picture of progress when in fact you&#x27;re headed in the other direction.<p>It&#x27;s not that tools are bad. It&#x27;s that our natural inclination to add in abstractions easily leads to code where it&#x27;s more important than ever to thoroughly test exactly what the code does. If we focused on the testing part first, the tools part wouldn&#x27;t be an issue. But instead we focus on tools and schedule pressure, and this leads to total crap. We buy the tools&#x2F;framework because we believe that schedule pressure forces us to work &quot;at a higher level&quot; but instead that same pressure, combined with the cognitive diffculties of adding yet more layers to the problems leads to a worse state of affairs than if we had simply skipped the tools to begin with.<p>I&#x27;ll never forget the shocking wakeup I got as a developer when I realized <i>I am a market for people selling me stuff, and these people do not have the interests of my clients in mind. They only have to sell me, not provide value</i>.<p>And yes, you can argue that there&#x27;s a requirements problem, but whenever something goes wrong, isn&#x27;t there always a requirements problem? Nobody ever asks for a system that&#x27;s broken, so whenever a system is broken, you can say &quot;But you never told me not to do X&quot; and be correct. The fact that requirements are a problem is tautological.<p><i>I stood before a sea of programmers a few days ago. I asked them the question I always ask: “How many of you write unit tests on a regular basis?” Not one in twenty raised their hands.</i><p>Bob&#x27;s right. When you see results like this, stay away from as many tools as you can at all costs. You don&#x27;t give hand grenades to infants, and programmers who aren&#x27;t testing don&#x27;t need faster ways to complexify the system in non-intuitive ways. The mistake this author makes is not realizing the reasons unit testing and TDD keep getting more important year-by-year. The mistake Bob makes is not diving down deep enough for some readers. &quot;Craftsmanship&quot; is a fine label, but there&#x27;s a reason we need this stuff aside from just wanting to be professionals. If more folks understood the practical and pragmatic reasons for the zeal, there&#x27;d be less confusion.