Scalable APIs

Chris Anderson talked about Scalable APIs a few days ago. Considering that my day job involves designing APIs that will eventually be used by thousands of developers, the points raised in his post are things I constantly think about. I've read Chris's post about ten times since he first posted it and the one thing that comes through loud and clear is that I completely disagree with it. It seems Doug feels the same way.

One mistake I see some folks at B0rg County making a lot is that they assume that there is no difference between people who need a "RAD" API and does who need an "Expert" API. A RAD API is full of helper methods and attempts to hide the complexity of the underlying system under a veneer of simplicity or simplified access. This API is very useful for the average developer writing quick, one off applications where development speed is of the essence and the requirements of the application are not sophisticated. An "Expert" API is typically needed for sophisticated scenarios where fine grained access to the innards of the technology are needed. The difference between a RAD API from an Expert API is the difference between using printf to display data on the console and using curses for the same purpose.

From my experience using B0rg APIs, it seems many B0rg API designers believe they can bridge the gap between the needs of the printf users and those of the curses users with their APIs. What typically ends up happening is that we end up with printf++ APIs where 90% of the task takes 10% of the time because of how easy it is while 10% of the task takes 90% of the time [or is impossible to do] because of the hoops one has to jump through to get things done.

Much worse is the fact that the "Expert" API is typically hacked together and inelegant because the core driving scenario in the design process is the "RAD" API user. The "design patterns are unnecessary" mindset is a prime example of this. Then the "Expert" API user has to resort to ugly code or hacks to perform tasks that should be directly supported by the API's design. Luke Hutteman decries the lack of MVC in Winforms because it leads to unnecessarily tight coupling between [what should be] the view and the model.

My goal in designing hacking RSS Bandit was to have the front end be completely pluggable because the back end was not tightly coupled to the UI. The fact that Winforms is not designed using the MVC model made this harder than it should have been.

When I look at the XML APIs we shipped in version 1.0 of the .NET Framework I see a lot of RAD APIs that make working with XML a breeze for people who just want to quickly grab an XML file from disk, move around it, tweak it, transform it and then save or display it somewhere. On the other hand people who want to build more complex frameworks with our XML APIs may not have been as well served. Our "Expert" API suffered because we had been "RAD" API focussed. However given that the number of people who just want to mess around with XML files is orders of magnitude larger than the number of people building XML frameworks, from that perspectives the API is a success.

There is a significant difference between the needs of the user of the "Expert" vs. the "RAD" API and pretending there is none guarantees that one either builds an API that overly favors one kind of user over the other or creates a Frankenstein API that is liked by neither.

#

On Getting A New Car

Half the people that voted in my last poll on whether I should get a new car think I should keep my Corrolla. I've thought the same thing for the reasons ucblockhead mentioned. The money saved is a very compelling argument especially in this economy but I can't seem to get rid of the feeling that I've had since college that the Corolla was just something I got out of necessity but would be upgraded to something I actually wanted (as opposed to something I needed) when the time came. Decisions, decisions, decisions.

By the way, I'd like to thank trhurler for his detailed car advice. That was madd cool.

#

A Star Is Lost

After my Saturday post on the 3 things B0rg Central could do the make their developer community happier I got an email from David Stutz who has most recently been the public face of the Rotor project. David has left the B0rg and mentioned that some frustration with the things touched on in my Saturday post were contributing factors in his decision.

This is unfortunate because I know David was an internal champion for Open Source and *nix while he was in the Belly of the Beast. Although David and I never really hung out I was inspired by what he achieved with Rotor and he was a role model of sorts with regards to the kind of impact he had on how Microsoft treats its developer and user community.

Reading his farewell email I can't help but wonder whether the B0rg can change.

#

Semantic XHTML or not.

Tantek recently said the following about the fact that I wrote a stylesheet that converts his weblog into an RSS feed

Uh, folks, looks like I've got an RSS feed (except the entry titles appear to be missing their last characters). Doesn't this mean that anyone can provide RSS feeds for any/all blogs that use valid and semantically rich XHTML? I have to consider the implications of this a bit more.

So I fixed the chopped characters in the entry titles. Anyway, what is interesting about the above statement is that when I was writing the stylesheet for Tantek's blog I was thinking the exact opposite. I was mildly irritated that XHTML for Tantek's blog was mostly presentation crap that I had to process via glorified regexes (i.e. tree matching in XSLT on presentation elements) instead of processing semantic information.

If you look at the stylesheet I wrote for Tantek's blog you'll see path expressions like html:ol/html:li/html:ol/html:li and html:ul/html:li/html:p[1] which to me is just one notch away from screenscraping using regexes. If this is the kind of "semantic markup" XHTML has to offer then it isn't much of an improvement over HTML. This seems even more evident when one looks at tools with features like Syndirella's Web Feeds which can do what I did for Tantek's XHTML with plain old HTML.

#

ThinkGeek T-Shirts for Testers

Joe Bork has a top ten list of T-shit slogans for testers with a few funny ones showing up in the comments. My favorite is We have jobs because you can't code.

#


--
Get yourself a News Aggregator and subscribe to my RSSfeed

Disclaimer: The above comments do not represent the thoughts, intentions, plans or strategies of my employer. They are solely my opinion.