--- title: "Describing and evaluating API usability at Microsoft" url: "https://osherove.com/blog/2003/10/8/describing-and-evaluating-api-usability-at-microsoft.md" canonical: "https://osherove.com/blog/2003/10/8/describing-and-evaluating-api-usability-at-microsoft.html" published: "2003-10-08T06:58:00" updated: "2003-10-08T06:58:00" tags: ["Cool Articles", "Off Topic"] author: "Roy Osherove" description: "BradA (wouldn't it be cool to just write “Brabrams“?:) posts about Describing and evaluating API usability at Microsoft . It's a power point presentation that describes just what you should be thinking about when…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Describing and evaluating API usability at Microsoft By Roy Osherove October 8, 2003 In [Cool Articles](https://osherove.com/blog/category/cool-articles), [Off Topic](https://osherove.com/blog/category/off-topic) **Historical article** · Originally published October 8, 2003; technical details may be outdated. [BradA](http://blogs.gotdotnet.com/BradA/permalink.aspx/754c3e0c-ee8f-49b6-8fef-992ee303cefa) (wouldn't it be cool to just write “Brabrams“?:) posts about [Describing and evaluating API usability at Microsoft](http://www.gotdotnet.com/team/brada/describingandevaluatingapiusabilityatmicrosoft.ppt) . It's a power point presentation that describes just what you should be thinking about when designing a programing API. I'm still a little unclear about some of the terms in there, but overall it's an enlightening experience. I like the idea of using “personas” to describe the 3 general types of programmers out there. I was wondering whether I'm considered a “systematic” or a “pragmatic” programmer. Having read “The Pragmatic Programmer” I'd assume to be the latter, but I'm not sure according to the descriptions in the ppt. One thing I liked is how each programmer type likes to use their APIs. I can definitely see these in real-life. An “Opportunistic” programmer will usually grab what they can from an API to just “get this task done” and not try to learn anything new in the process, how this API affects other system code, or just this Application's code. Although I'm sure I used to do stuff like this, for the life of me I think it would be down right impossible to do now. For better or worse, I can't help learning new APIs and getting "deep" inside them to understand their full impact on lots of other stuff. I \*have\* seen a lot of other developers(or should I say "programmers") do this. It usually leads to code that sometimes looks ridiculous; something like some of the visual basic examples you find on MSDN , that show you how to do simple tasks using cut-n-paste from VB Script examples(late binding ,variants and all that). It's also usually hard to maintain such code. ## More in Cool Articles [All posts in Cool Articles](https://osherove.com/blog/category/cool-articles) - Nov 4, 2003 ### [\[Article/Code\]: Easy Proxy handling through the ProxyFactory and ProxyInfo classes](https://osherove.com/blog/2003/11/4/articlecode-easy-proxy-handling-through-the-proxyfactory-and.html) - Oct 15, 2003 ### [\[Article\] on MSDNAA: Creating a Generic Site-To-Rss Tool](https://osherove.com/blog/2003/10/15/article-on-msdnaa-creating-a-generic-site-to-rss-tool.html) - Oct 6, 2003 ### [Excellent TDD articles, and a Code Kata](https://osherove.com/blog/2003/10/6/excellent-tdd-articles-and-a-code-kata.html) - Oct 6, 2003 ### [Getting a focus on performance - some new pages](https://osherove.com/blog/2003/10/6/getting-a-focus-on-performance-some-new-pages.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/