My former colleague and present friend, Andy Edmonds, deleted my ignorance of Jakob Nielsen’s “10 Commandments of Usability.” When striving toward a usable product, let’s consider:

1. Visibility of system status
2. Match between system and real world
3. User control and freedom
4. Consistency and standards
5. Error prevention
6. Recognition rather than recall
7. Flexibility and efficiency of use
8. Aesthetic and minimalist design
9. Recovery from error (barring #5)
10. Help and documentation

Immediately I started to think about how these usability heuristics apply to software development. As developers, we are in an unique situation. We make products for users, ideally very usable products. If we look a little deeper though, the stuff that makes the product for our users is itself a product. Our source code and development environment is a product.

Let me try that again: the technical components (source code, repository, CI config, tests) of the applications our end users consume is a product in its own right. Our code is a product for which we are the users.

In the next few posts I’ll detail how these usability heuristics apply to our development environments using a simple template. For each guideline I’ll cite an example in traditional user experience, followed by a relation to development environments. I’ll follow this with an example of how the heuristic applies to our code as a product.

Stay tuned…

I have this niggling suspicion that you can observe the evolution of a developer by sampling their opinions about configuration over a three to five year period. Stay with me…

In the beginning configuration seems like an awesome power. You can change the behavior of software at run time. You can put said power in the hands of users, or, as is more often the case, you can automate boring chores freeing yourself for the hard problems, the real interesting ones. Are you clever? Heck yeah.

Then, at a certain point, you observe the hard problems become maintaining the very mechanisms of configuration: the fruit born from the seed that is your inventive mind becomes a ball and chain. Changing behavior has become a tedious maintenance task in and of itself. Compound this with the fact that users haven’t taken the configuration into their own hands. You’ve just removed skill from your gig.

Ok. Fine. What to do?

I know! This job is tedious, so let’s remove some of the window dressing from this configuration nonsense. XML? Pish posh; we have YAML! That’s way fewer movements in VIM and how could we be so obtuse in the first place.

Still, after a time, you have a devil or angel or both camping on your stiff shoulder who is persistant and annoying and relentless in asking, “why are you still doing this busy work?” Sooner or later you’ll stop questioning whether this entity is a guardian angel or a personal demon and cut to the heart of the matter; Jesus H. Christ is telling you to develop software for his dad’s sake.

Executable configuration leads us back to what we should be trying to do best: solving the problems of our users. Hey! All of a sudden we’re coding again!

Do you follow this? Where are you on my proposed evolutionary timeline? Maybe it’s not too late to eschew the all-consuming fear of asteroidal impact for taking interest in finding a sustainable environmental niche.

I have to credit my colleague Steve Harman for enlightening me on this topic. I had this instinct, this configuration aversion (which mainly manifested itself through a cranky attitude), but he really brought it to the old frontal with a pithy team room rant going something like this (and I paraphrase):

Why the fuck are we using YAML for Rakefile config when Ruby has hashmaps and, um, hello today, Ruby?!

I’ll lean on Steve for concrete examples. Yesssss!

A mini-conversation just erupted in the VersionOne team room about how we do test first, BDD, what-have-you. A couple of the developers here made explicit the notion that they like to figure out the behavior (or observation) of the next design test they’re about to write, then figure out the context.

I’m a fan of this approach; it seems to align more with the way the human brain works. Let’s unpack this a little bit.

First we ask the question: “what do we want the system to do here?” Or, perhaps it’s more accurate to say, “what is this bit of acceptance criteria telling is we need to make the system do?”

Following this approach while adding behavior to an existing personal banking system, we might end up with a bit of RSpec code that looks like this:

Notice that our context is inside of our specification. Once we’re certain with that behavior we may refactor to something like this:

If we had a refactoring language for TDD, we might call this “Extract Context.” Point being, taking this approach seems simpler to me. We formalize things in a very natural way and it helps us stay closer to the benefits of TDD (again: simplicity).

As a coach, you’ll likely find yourself doing a lot of facilitation when introducing practices. Examples include getting retrospectives up and running or sparking creativity during product design sessions when you’re putting together a release plan. Having the right equipment can be invaluable.

The Contents

I do a workshop from time to time, called “Leading Design.” In essence it’s for coaches who lead design-intensive software teams. A lot of the equipment in my bag is aimed at getting the innovation out, breaking the damn logjams that dam our creative juices. This is an exploded view of the gear I bring as of today:

1. Post-Its. Lots and lots of post-its. I like the really big, really bright ones, but I also bring your standard 3″x3″ ones. Having a variety of sizes helps in some of the exercises I do like activity modeling.
2. A tomato kitchen timer. I use the Pomodoro Technique in my workshop (try to, anyway). Dave Hussman brought this idea into my world. Hell, he gave me the timer!
3. Five sets of six-sided dice. I do an exercise to demonstrate the effects of variation. You can buy The Red Bead Experiment for ~$200.00 USD or you can buy a bunch of dice at a southern flea market for $1.00 USD.
4. Objectified, a documentary about product design. I use this to reinforce some of my assertions that since software is a kind of design, we can borrow a lot from the design community.
5. Rules for Radicals by Saul Alinsky. This is the handbook for organizing change. I call it out a couple of times in my workshop, and like to re-read a couple of key passages to get fired up.
6. A Ball of Whacks toy. I’m kind of considering how to use this in my workshop. If nothing else, I can leave a couple on the tables for people to kill time in a creative way between exercises and mini-talks.
7. Several decks of cards. On the top is Brian Eno’s “Oblique Strategies” deck. He uses this in the production studio to unjam creative blocks. An example strategy: honour thy error as a hidden intention. The bottom two decks, “The Creative Whack Pack” and “The Innovative Whack Pack” are from Roger van Oech. Each card give you is a tool for unlocking creativity and innovation, thinking from different perspectives, etc. I love them and have written about them before.
8. A bunch of different-colored sharpies and a good dry erase marker. More-or-less self-explanatory.
9. A slide whistle. Rather than go with the typical Tibetan store equipment (chimes, bowls, gongs) favored by most Agilists, I went with something slightly more absurd.

The Container

Select a bag that can take a beating, something that will protect its insides. Mine is really just a tool bag, made of super durable Cordura nylon (meaning that it is nigh indestructible). It fits in my travel backpack and the shoulder strap is convenient for toting my gear back and forth (both useful features for mobile coaching and workshop delivery).

One really awesome thing is that there are tons of pockets, inside and out. I don’t keep anything in the outer pockets while traveling, but do use them to get setup and put things I’ll need in a handy area for quick access while facilitating a session.

Drop Ship the Rest

The rest of the stuff (projector, whiteboards, index cards, butcher paper, tape) I source locally. A little recon is helpful here. Where is the nearest office supply store, or, if you’re in London, stationary shop? I tend to rely on the locals and beneficence of my hosts.

Now a Word on the Unimportance of Gear

Coaching, unlike camping, isn’t all about the gear. Your most important tools are your ability to get the context of a situation (listening) and to think on your feet (adaptation). Sometimes gear can be a distraction. Even so, having a basic supplies and thought toys can help get the ball rolling. Simple tools that help people unleash creativity in complicated situations or explain ideas where words fail are super handy. Coming prepared? Well, that’s just indispensable.

My friend Shawn and I were having a conversation the other day about cranky designers. He mentioned the experience of living with a hotshot designer ex-girlfriend who was critical about all the products they chose to place in their home. Critical, perhaps, isn’t the right word. Let’s go with disgusted.

I see evidence of this from all kinds of designers, self-included. Take the movie Objectified, a documentary about the process and significance of product design (industrial design). One of the common emotions you’ll see designers such as Marc Newson express is disgust. Designers find annoyance in poorly thought out solutions and seek to redefine these solutions in harmony with their needs. Frustration, annoyance, disgust, discontent, vexation… these are negative reactions that lead to innovative solutions.

I like one of Roger von Oech’s many excellent creative thinking tools as a means of getting over apathy or an overly high tolerance for pain. He says, be dissatisfied:

Disastisfaction is beneficial to the creative process. Otherwise you lose the prod you need to spot potential problems and opportunities. Success can make us complacent. We think, “everything’s fine. why change anything?”

Too often in software I think we settle, or – even worse – fall in love with our creative babies. We’ll make excuses for the shoddy parts and become defensive when we receive criticism. This goes both ways. Perhaps you’ve let a fear of upsetting the group or incumbent developers prevent you from discomfiting a design that creates discomfort? I know I have.

Disgust is a valid emotion, and you should pay attention to it. Even so, you may want to consider how you express your disgust within your pod. While you owe it to your customer to not become an apologist for crappy design, you either (1) owe a measure of respect to your team or (2) should be looking for a new gig. Consider the feelings of people that might have more time, blood, sweat and tears invested in that thing you’re about to rip apart, even if your ire is justified, irrefutable. A dollop of respect will help you affect positive change like nothing else.