More on API Usablity Study

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">In the comments of one href="">of
my recent posts the need for more information about API usability studies
came up.  style="mso-spacerun: yes">  "urn:schemas-microsoft-com:office:smarttags" />Steven
, a usability engineer at Microsoft came up with this
formal way of describing API usability. We use this model internally to evaluate
and improve our APIs as well as input into the design guidelines
document. "urn:schemas-microsoft-com:office:office" />

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Love to know what you

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> href="">Describing
and evaluating API usability at Microsoft

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">API usability studies are not the
end-all-be-all, but they are a very interesting data point.

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">

Comments (6)

  1. Shane King says:

    Thanks for sharing that, it was interesting. I think the idea of the three types of programmer (oppourtunistic, pragmatic, systematic) is kind of problematic, as I think I’d fit into any of those three roles depending on what I’m working on. Perhaps that’s the point, but it’s jsut not covered by the slides?

    Anyway, I know it really bugs me when I have an API that seems built for one mindset when I’m in another. For example, if I want to hack something quick and dirty out, I’d be in what the document describes as oppourtunistic mode I guess, and am frustrated when the API wants me to build everything up from first principles.

    Likewise, when building some core functionality I need to work in exactly one specific way, I get systematic, and it really gets difficult when I can’t make something work the way it needs to because the level of abstraction is too high.

    A good API should probably offer services at multiple levels of abstraction, but of course that negatively impacts on the amount of stuff there is to learn. I’m not sure much out there really gets this balance right though … there seems to be a large gap between "almost enough to be useful" and "kitchen sink". 😉

  2. John Cavnar-Johnson says:

    The ideas look very interesting, but it’s hard to get a good grasp of this from just the slide deck. I would love to see a guest blog by someone who can explain these concepts. This is also the kind of stuff that would make for an interesting change of pace at the PDC.

  3. Steven Clarke says:

    I’ve tried to provide more explanation of the cognitive dimensions framework at my blog – see

    You make a good point about the different programmer personas Shane. You’re absolutely right that people do tend to switch between the different types. However, we’ve found that most people tend to stick to one type for the most of their development and so we’ve found it useful to describe these stereotypes as distinct personalities.

  4. David Dillard says:

    Can you provide your definitions of systematic, pragmatic, and opportunistic programmers? (A quick Google search didn’t turn up anything other than the presentation that contained these strings)

    Also, can you give examples of what’s meant by factored and aggregates? It’s not clear from the slides.

  5. Steven Clarke says:

    Here’s a brief definition of the different programming styles we represent in the opportunistic, pragmatic and systematic personas. Remember that personas are by their nature stereotypes and that certain behaviors and characteristics are somewhat exaggerated.

    Systematic programmers tend to follow a defensive coding style. They do not make assumptions about the code they are writing, the platform it runs on, the class libraries that they are using etc. For example, they do not assume that a class library will behave as advertised. Instead, systematic programmers will test the library in a safe environment, inspect the library source code etc before using it in a production environment. Systematic programmers desire programming languages and APIs that give them full control over the execution of their code and that do not hide important details from them, even if it means they have to write more code and take more time to understand how the code works. They value being able to get under the covers and tinker with components or even replace them.

    Pragmatic programmers tend to be less defensive than systematic programmers. In many cases, they are comfortable trading off control for productivity as long as they are aware of the existence of the trade off. Rather than spend the time understanding the full working details of an API, they will prefer to learn as they go, building up an understanding of the API, programming language etc in the context of the work that they are doing. They value being able to get under the covers and tinker with components should they need to, but will prefer not having to do so.

    Opportunistic programmers value productivity features in a language, API and IDE very highly, often higher than anything else. Unlike systematic programmers, they place less value on having complete control over their code, since for opportunistic programmers, the cost of control is added development time. They particularly value 3rd party controls and APIs that allow them to concentrate on the business problem that they are trying to solve, rather than on configuring the control or specialising the API so that it meets their requirements. They don’t really value being able to get under the covers and tinker with components – they would rather look for some other API or control that met their needs instead of modifying controls or APIs that they already have.

    As for examples of factored and aggregate components, an example of a factored componnent might be System.IO.StreamWriter which encapsulates functionality for writing to a file. A fictional aggregate (at least in System.IO anyway) might be a File class that encapsulates functionality for writing to a file and reading, as well as creating files, deleting files etc. Factored components tend to expose functionality for one core task while aggregates expose functionality for a core set of tasks. Factored components can usually be combined with other factored components in interesting ways, while aggregate components tend to be used as-is.

Skip to main content