On Amsterdam & APIs

Amsterdam, the City

Any description of the event has to start with discussion of the incredible host city. As explained by a native, Dutch culture has always been one of trade. That is reflected in the language (everybody can converse easily in multiple tongues, including crystal clear English) to food (try the Indonesian, seriously), to culture. In two words, things are integrated and copesectic.

The venue's outward facade, for example, was a brick building with murals from Danish life at the turn of the 20th century. Inside, presentations were held inside a towering chic cube of glass, more modern art than historical shrink wrap.

Likewise, the infamous "red light district" at the heart of Amsterdam felt more festive open air bazaar than skeezy backwater. A church was across from a sex shop, down the street from a cheese maker, around the corner from a cannabis vendor; everything is there and simpatico as if any other way would be silly. The contrast did not form lines oxymoronic moral conviction but rather illustrated the sharp relief with which American society demarcates things.

Consistency vs. Novelty

The conference kicked off with Ken Wronkiewicz (@wirehead) talking about "Software as a City". He mentioned the story of why railroad tracks are spaced the way they are, and have been for hundreds of years. Then, as Ken explained, the Bay Area Rapid Transit System began work on their own rail network in the 1960s to serve the San Francisco region. They did not follow the previous conventions and, as a result, pay exorbitant multiples of other municipal light rail systems because of the custom everything.

Ken's point is that all systems go through Cambrian explosions of disruption and novelty. However, at some point those ecosystems establish norms and standards. In order to grow, whether it is APIs or railroad tracks, consistency for pieces networked together is important. With web APIs, we have reached the point in which it is better to be consistent with the best practices than novel in our execution.

There are exceptions to this, of course. Hypermedia APIs remain an area which is going through it's Cambrian phase. There's seemingly a new media type popping up for discussion on industry forums every-other week. The trick is to watch the tooling. Right now developers are almost exclusively hand-rolling their own solutions. When things have standardized enough that vendors can program against it then we know that an area has reached a tipping point.

An API Vision (API Leap of Faith)

Mehdi Medjaoui (@medjawii) was quick to remind the audience of our favorite API metaphor, Lego Bricks (considering our proximity to Denmark, it was appropriate in more than one way). As builders, however, our conceit is that we can't see the forest for the trees. If we could have a vision for the pieces beyond the code immediately in front of us we would do things differently.

He proposed a set of principals that, if broadly adopted across APIs, would enable the fulfillment of these grandiose visions. The tenants of such an "Open API Standard" are:

1. Add something new to the network. Having dozens of different image manipulation APIs doesn't help. Instead, the fragmentation causes confusion and delay.
2. Be transparent. Walled access to datasets is a short term strategy. This leads to industries, like real estate, ripe for disruption. Business models should be based on service, not uniqueness of the data.
3. Be accessible. Documentation, code samples, pricing information — all of these things aren't post-development cleanup but essential considerations during development.
4. Play nice with others, or interoperate. While the de facto standards for web APIs remain in flux, that doesn't mean we shouldn't strive for levels of consistency (see Ken's talk).
5. Address legality (I'm combining Mehdi's seperate policy and terms of service points into a single need). Another sign of discipline maturity, Mehdi was one of many calling for better API policy towards attribution, derivative works, and data ownership. While hackers grouse at perceived "overhead friction", these things are necessary to ensure confidence for companies to build their business on someone else's platform.
6. Aspire to neutrality. We can't all have the same vision. If possible, be neutral in architectural decisions to allow for the greatest number of possibilities to flourish.
7. Be reliable. We all got a kick out of the fail whale. But it's no longer 2007 and institutions incorporate Twitter for Amber alerts, incident notification, and crime investigation. If APIs are advertised as infrastructure then they have to have the up-time of any other utility. You don't open a toilet lid and discover the water is 404 Not Found.
8. Build the Commons. We shouldn't be re-inventing the wheel. Odds are other API developers would benefit from non-differentiating work. These are things like frameworks. When possible, developers should contribute back to places like the API Commons to accelerate the work of others like them.
</li>

As Mehdi correctly pointed out, none of these things are easy. However, if we take the leap of faith to implemented our APIs in this way, we will scale with greater ease.

Automata, Scaling, & the Internet-of-Things

The final event talk I wanted to highlight came from Mike Amundsen (@mamund). In an evocative presentation Mike discussed the challenges that developers will face in the coming Internet-of-Things era. Already underway, instead of (best case) having to support millions of users we'll now be asked to support tens of billions devices. A logarithmic leap will require new approaches.

To prepare for such a future Mike told the stories of three individuals — Von Neumann, John H. Conway, and Theo Jansen — who each, individually, hit upon the idea evolvable systems for problem solving. Rather than coding solutions, these systems, called automata, would be given rules and then allowed to create solutions on their own.

Software, as we know it, will not be able to scale for an Internet-of-Things. We cannot continue writing every line of every step along a pre-determined path. Instead, programmers will need become more akin to farmers: nurturing a complex set of inputs to yield a bountiful result. They will need the eye to prune the branches unlikely to bear fruit. Their experience will dictate when to harvest and when to leave a problem set fallow. Developers of the future will be tenders of a software garden rather than worms excreting line after line of endless crap.

This is such a powerful shift in perspective that I want to marinate on specific points in future posts. However, if this sounds appealing you can get started with Mike's notes. He's got a blog post about this, too. The video is below.

Conclusion

Some big ideas there and I only covered three talks of what was presented over three days! As our software continues to become more complex and interconnected these are the kinds of conversations we need to be having. A hat tip to Kin Lane and Steven Willmott for providing a forum for those to occur. I only hope I have the time digest the intellectual challenges issued by the Amsterdam API Strategy and Practice Conference before the next one arrives!