Coding Horror

programming and human factors

Developers Are Users Too

I'm currently whipping up a mini-API for the BetaBrite-specific subset of the Alpha Sign Communications Protocol. Naturally, I want it to be easy to use and understandable for other developers-- a classic usability problem. How do you approach usability when your audience is other developers?

The answer is, unsurprisingly, exactly the same way you approach usability for regular users. Microsoft's Steven Clarke has an entire blog dedicated to this subject, and he's been conducting regular usability labs on the entire alphabet soup of upcoming Microsoft technologies. There's a somewhat dense summary of his results (powerpoint), and it's all bread-and-butter usability studies. Nothing developer-y about it. Personas, use cases, tasks, and a whole lot of observation. Here are a few representative examples from his blog, which I highly recommend.

On Attributes:

I think one factor in this is the low visibility of attributes. For example, one participant in the study this week was stepping through his code in the debugger when he noticed some unexpected behavior at some point during the excecution of his code. He was focused on a particular block of code and concentrated his efforts on understanding how that block of code might have caused the behavior he had just observed. The cause for that behavior was due to an attribute that had been applied to the class that defined the method the participant was stepping through. Thus when he was reading his code, the attribute was well out of his focus of attention.




When it comes to usability, there's no substitute for observation. It's absolute bedrock.

One thing that jumped out at me almost immediately was the importance of good code samples. Those are the first things I look for in any new enviroment I'm exposed to, and for better or worse, they set the tone for my experience. But, as Steven describes in a Dr. Dobb's Journal article, Measuring API Usability (PDF), you have to be careful that you're not papering over bad API design decisions with good code samples:


This is something I've touched on before. If you're answering a lot of questions from other developers about something you've written, it's probably not because your co-workers suck.

Written by Jeff Atwood
