May 6, 2011
"Sufficient Design" - Something To Aspire To For The 99% Of Us Who Aren't Even Capable Of ThatSo I'm not at the Lean Software & Systems conference in California, but it's hard to miss the tweets.
Joshua Kerievsky's talk seems to have gone down very well, with many tweets about "sufficient design". The basic idea is that our software only needs to be good enough, and time and effort spent makming it better than that is time and effort wasted.
There's an implication buried somewhere in there that "software craftspeople" take quality too far, and are therefore potentially wasting time and effort making their code too good.
I completely agree in making code only as good as it needs to be. But I think maybe people - especially people who have a bit of a chip on their shoulders about craftsmanship - latch on to the idea of "sufficient design" as a justification for not bothering to make their own truly not-good-enough-and-then-some code any better.
The reality is that "good enough" code is a rare thing, and code that's better than it needs to be is almost unheard of. I've never seen code that was too good for its purpose.
The craftsmanship movement is full of people who aspire to one day write code that's as good as it makes sense to make it, and possibly to even be capable of making it better than that, just in case.
Businesses that buy into the mythology of "quick and dirty" to get something to market or to solve a problem sooner are buying into a lie. In the vast majority of cases, taking more care over quality would actually enable teams to go faster. I'm not just saying that: the weight of evidence is on my side. Studies done by IBM, the Software Engineering Institute, Microsoft and many other esteemed (and maybe slightly less esteemed) bodies have provided us with a mountain of hard data that indicates beyind any reasonable doubt that it doesn't cost more to deliver software that's more reliable and more maintainable. In many cases it actually costs less. As Robert C. Martin is fond of saying: the way to go fast is to go well.
Let's cut to the chase. I know from personal experience that when I cut corners and "kludge" a solution, it takes me longer to get it working. So if I made a "business decision" (and, seriously, when did we all turn into Alan Sugar?) to lower the quality bar, I'd be deliberately choosing to deliver a less reliable, less maintainable solution and to do it at greater cost in time and money.
Here's what I think. I think people like Joshua Kerievsky and others who talk of "sufficient design" have actually passed that point where greater quality can be delivered at lower cost. They are in a very small minority who've been applying a level of skill and discipline that does not always make sense economically.
The rest of us are probably on the other side of that curve, and we should be eyeing them enviably. We should certainly not make the mistake of thinking that their advice on sufficient design applies to us. Not yet. Not until we've passed that well-documented "sweet spot" of maximum quality and productivity.
Until that day, we should continue to focus on doing it better and learn to accept that "sufficient design", to the rest of us, is something we should aspire to.
You see, for apprentices like you and me, worrying about making our code too good is as misguided as worrying about being too good in bed. And, of course, if you give a talk about "sufficient lovemaking" to an audience of mostly men, you're going to see a lot of people nodding in agreement. In that hypothetical situation, would you presume that the guys nodding are the ones who have genuinely experienced this problem of being too good in the sack?
No, me neither.
Posted 7 years, 1 month ago on May 6, 2011