One of the more frustrating things that nerdherders (and nerds) have to deal with is omnibus information - those annoying emails or bug reports that contain an often random collection of requests or problems all mashed together in a series of loosly connected paragraphs and long lists of dot points. They are hard to archive/file and if an email reply is warranted then the different issues get in each others’ way. When they are but in front of your more organised and anal-retentive nerds they say to him/her “I am sloppy and don’t care about information, I can’t keep track of my thoughts and don’t really care if you do either”. Basically, this sort of information is less useful that it could be and makes the job of those interpreting it harder than necessary.

Making it easy for your friendly local nerds to serve you better can be done by following a few simple guidelines. So without further ado here is the Nerdherding guide to helping yourself with requests to nerds:

1. If you want to talk about two unrelated issues or problems then send two emails or create two bug reports. They can then be nicely moved through any process without tripping anything else up.
2. If you feel the need to conserve bits and simply must combine multiple unrelated issues then please clearly number or label each separate item. I’m amazed by often in my career I’ve had to deal with work requests containing dot-point lists - its embarrasing for everyone when I have to say “tenth dot point in the second list”.
3. If you have to communicate a high priority issue with other less important issues then please separate out the high priority issue. Its less likely to get lost in the noise and means that the less important issues won’t be ignored.

P.S. I must admit that sometimes I tend towards the “organised and anal-retentive” end of the spectrum.

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.

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.