Once in a while a software project begins to go wrong. You know the score. Each day another critical bug appears in module X or the completion date for feature Y slips by a day. The team keeps working hard and produces stuff. Every day you are sure you’ve broken the back of the problems but then another appears. It saps your spirit and makes the team doubt themselves.

There’s a secret that comes with experience that you probably know. In fact there’s a saying that pretty much sums up the secret:

“If you find yourself at the bottom of a hole then the best thing to do is to stop digging.”

Apply this idea to the project going wrong. Is it really just a series of small incidents that, through a run of mind blowingly poor luck, have all started to bedevil the project one after another? Perhaps a more likely explanation is that there is a fundamental problem that is now showing its head. Is your development process out of control or inappropriate for your team or the project? Perhaps you have a poorly designed module that is poisoning the well. Maybe there is a bad assumption in the business design of the application. Who knows. But maybe, just maybe, there is a single more fundamental reason why the project has gone of the rails. Your mission is to discover the fundamental problem. Good luck.

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.

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.