Lasse makes a good point about my Elegant Sufficiency post. Defining design thresholds is hard, very hard. The only way I think they can be practically defined (or identified) is with reference to a codebase since design thresholds are implicitly embodied in the practices of a team and in the work they produce. This avoids the need for an official, written guide to good design for team X, which would be useless anyway.

The other main subject of Lasse’s post was to discuss the benefits of “asking the team” and voting to decide whether a particular design sits within the thresholds. I think this is necessary and a great way to encourage emergence of a common set of design thresholds. As to whether the thresholds will produce elegantly sufficient designs - well that sounds like the subject of another post. Off the top of my head I’d assume that this is where a “benevolent dictator” (or two) could do some dictating to help things along.

I like to re-design (refactor, whatever) things when they fall below a certain quality level and don’t feel comfortable improving things above a certain quality level. In other words, there is a band in which I like designs and implementations to sit that is somewhere between good enough and elegant. Call me a pragmatist. Call me a person who likes things that are elegantly sufficient.

Unfortunately, I’m not great at abstractly describing elegant sufficiency or exactly where my thresholds lie. Worse, sometimes my quality thresholds change as I learn new things or forget about past bad experiences (although this is a gradual process). Even worse, if I’m considering the work or design of others, then my thresholds are different depending upon which particular other is responsible.

Apparently I’m an arbitrary manager. Sorry. At least I’m aware of it, willing to admit the fact and can describe why I’d like a re-design. Some of the most furious design conflicts I’ve seen have been caused by people being unaware of others’ thresholds and not being able to discuss their own thresholds in an abstract way (”What’s your problem? It works doesn’t it?”, “But all functions in an interface must be orthoginal!”).

This brings me to Michael’s design threshold laws:

1. For a team to work well together it needs to establish a common, congruent set of design thresholds.
2. For a team to be successful it needs to have design thresholds that produce elegantly sufficient designs and code.

Seth Godin wrote a post in which he is critical of creating things that are good enough. He is saying that good enough is the opposite of the pursuit of better (or as he calls it the relentless pursuit of better).

This is, to borrow a phrase, crazy talk. Good enough is an important stopping point on the way to better. If you don’t stop at good enough then you won’t ever reach better. I think that Seth’s own example of JetBlue turning one third of the toilets on its planes into a ladies only toilet demonstrates this. Did JetBlue delay launching their airline until this epiphany came to them? Clearly they didn’t. They created a package that was better than their competitors which had good enough aspects and great aspects. Coming back to make the good enough bits better is fine but they went with good enough knowing that waiting for better on everything would kill them.

Perhaps a better idea (sorry) is to make sure that at least some aspects of our products/services are better and that the rest are good enough and then made better as soon as is sensible. I wonder if Seth would agree?

Recent posts

Nerdherding for Beginners is written by Michael Harmer, released under the Creative Commons Attribution-Noncommercial 2.5 Australia licence powered by WordPress and designed by XiAP Design Studio.