Yes, Bob is my uncle too. I also think the points in the Manifesto for Software Craftsmanship (manifesto.softwarecraftsmanship.org) are all great. What amazes me is that tend to confuse the term “well crafted” with “perfect”. I'm about to say something that will make Quality Assurance managers and many development types as well until you think about it as a craftsman – “Stop trying to be perfect”.
Now let me explain what I mean. Building software, as with building almost anything, often involves a series of trade-offs where either one undesired characteristic is accepted as necessary to achieve another desired one (or maybe stave off one that is even less desirable) or a desirable characteristic is sacrificed for the same reasons. This implies that perfection itself is unattainable. What is attainable is “sufficient” and I think that this really goes to the heart both of what people are trying to do with Agile and with the craftsmanship movement. Simply put, sufficient software drives the greatest business value.
I've been in many meetings where “how can we keep anything from ever going wrong” has become the thing that holds us in analysis paralysis. I've also been the guy trying way too hard to perfect some function to make sure that every edge case is accounted for. Somewhere in there, something a drill instructor said while I was in boot camp occurred to me. In response to being asked a question by another recruit having to do with some edge case (I can barely remember the context), he said “What if grasshoppers had machine guns? Would the birds still **** with them?” It sounds funny, but there's a lot of wisdom in those words.
“Sufficient” is different for every situation and it’s important to understand what sufficient means in the context of the work you’re doing. If I’m writing a timesheet application (and please shoot me if I am), I’m going to have a much higher tolerance for imperfection than if you’re writing software to control life support systems on spacecraft. I’m also likely to have less need for high volume performance than if you’re writing software to control stock trading transactions.
I’d encourage anyone who has read this far to instead of trying to be perfect, try to create software that is sufficient in every way. If you’re working to make a component that is sufficient “better”, ask yourself if there is any component left that is not yet sufficient. If the answer is “yes” you’re working on the wrong thing and need to adjust. If the answer is “no”, why aren’t you shipping and delivering business value?
