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:
- For a team to work well together it needs to establish a common, congruent set of design thresholds.
- For a team to be successful it needs to have design thresholds that produce elegantly sufficient designs and code.