Good Enough

I used to use this line all the time: “Well, it’s not art, but it’s good enough for Steve” To which, the person I was speaking to, would always ask, “Who’s Steve?” and I’d reply, “Art’s less demanding, younger brother.” I stopped saying that once it truly became clear to me that I was the only person who found it amusing.

At the XP Toronto session last week, we were talking about design: what constitutes good design, and what actions are agile developers supposed to take to build good designs. Two sound-bytes emerged from the conversation:

  1. “Good enough” design.
  2. Perfect is the enemy of good.

Both of these sound-bytes gave voice to the idea that it’s easy to get too caught up in trying to create the world’s best design. I think such a caution resonates well with agile folk who are constantly striving to do the simplest thing that could possibly work.

But I’m constantly trying to reconcile various things that I read from various books, and the second of the two sound-bytes conjured up memories of Jim Collins’ book, Good To Great. In it, he writes:


Good is the enemy of great.

And that is one of the key reasons why we have so little that becomes great.

We don’t have great schools, principally because we have good schools. We don’t have great government, principally because we have good government. Few people attain great lives, in large part because it is just so easy to settle for a good life. The vast majority of companies never become great, precisely because the vast majority become quite good — and that is their main problem.


I think that the problem that agile methodologies try to solve is the classic “90% of projects fail” problem. And if you’re just trying not to be part of that majority, I can see how stressing “good enough” is important. But there is a big part of me that’s seduced by really great code. I think that accepting code as good enough is a necessary evil. Like all necessary evils, it is something that one should practice, especially at first, but constantly strive to move beyond.

One of the questions that I asked at XP Toronto was, “what are the actions that agile developers take to implement design?” I find this question interesting in light of Collins’ work on Good to Great. He outlines a series concepts relating to moving a company from good to great:

  1. Disciplined People
    1. Level 5 Leadership
    2. First Who… Then What
  2. Disciplined Thought
    1. Confront the Brutal Facts
    2. Hedgehog concept
  3. Disciplined Action
    1. Culture of Discipline
    2. Technology Accelerators

I’m especially interested in the section on “Disciplined Thought”. Collins’ notion of a Hedgehog Concept relates to a simple analogy that he uses in the book. He contrasts the fox, who is wily and thinks up a dozen different ways to attack the hedgehog, with the hedgehog who really has once trick (roll up into a prickly ball), and thwarts the fox every time.

Collins says, therefore, that the truly great companies all seem to find one big thing and stick to it. In his mind, Hedgehog Concepts are motivated by three big questions (which he illustrates in a three-circle Venn Diagram):

  1. What are you deeply passionate about?
  2. What drives your economic engine?
  3. What can you be the best in the world at?

And then the Hedgehog Concept is refined by repeatedly iterating through the following process:

  1. Ask Questions, guided by the three circles
  2. Dialogue and debate, guided by the three circles
  3. Execute decisions, guided by the three circles
  4. Autopsies and Analysis, guided by the three circles

I feel like there are some interesting parallels between Collins book about companies and what one might be doing to get great design in code. I find myself wondering to what extent the XP’s former practice of a Metaphor is similar in intention to Collins’ Hedgehog concept.

There are aspects of the Hedgehog concept that feel very much like some object-oriented design concepts. The Single Responsibility Principle, for example, seems topical. I’m not sure, yet, if that’s just superficial similarity.

Certainly, Collins work requires some thought to translate it to the realm of object-oriented design. For example, what does it mean for a design to drive one’s economic engine? But I do feel like there’s a kernel of something really inspiring, there.

It's only fair to share...
Share on Facebook
Tweet about this on Twitter
Share on LinkedIn

Leave a Reply