The British API nerds are coming

I got off the plane with my family around noon the friday prior the event. It was freezing. It was raining. I didn’t cared. There I was in Boston. Not only to visit this wonderful city and its neighborhoods, I was there for APIStrat 2016.

It was going to be an awesome trip.
It was going to be an awesome conference.

After a few days of tourism, a panel discussion and the speakers dinner, it was time to go to API Strat.

Thursday. 8 am. I grabbed my speaker badge and the API Strat 2016 official t-shirt.

One if by REST
Two if by SOAP

This t-shirt was a bit cryptic for a foreigner like me. It seems that I was not the only one in that case.

Boston is a city steeped in history and it seemed that the american revolution hero Paul Revere or the american poet Henry Wadsworth Longfellow gave a hand to design this year’s t-shirt. This quote has been inspired by:

One if by sea
Two if by land

It was a signal, popularized by Henry Wadsworth Longfellow in his poem Paul Revere’s Ride that indicated if the british troops were coming by land or by sea in the days before the first military engagement of the American Revolutionary War, the battle of Lexington and Concord:

In the days before April 18, Revere had instructed Robert Newman, the sexton of the North Church, to send a signal by lantern to alert colonists in Charlestown as to the movements of the troops when the information became known. In what is well known today by the phrase “one if by land, two if by sea”, one lantern in the steeple would signal the army’s choice of the land route while two lanterns would signal the route “by water” across the Charles River
Source Wikipedia

Whether by sea or by land, the API nerds were coming. The API community was gathering in Boston. Not for a battle of course, but for a very friendly and inclusive conference. Speakers and attendees. Experts and beginners. Old friends and total strangers. All these people gathered to talk about APIs together whatever their so-called status. Finally, everybody got back home with new lessons learned, new ideas and most important: new friends.

This is bowling, there are rules

So many different people gathered in a friendly and inclusive event, what could go wrong? In an ideal world, nothing. But we do not live in an ideal world.

Thursday 9 am. Main Stage. The staff announced that someone has been expelled from the conference (the conference has started the day before with workshops, speakers dinner and attendees meetup).

In case you missed it, API Strat has a code of conduct. A code of conduct?
Yes, a code of conduct:

A Code of Conduct is a public statement that sets the ground rules for participating in an event Ashe Dryden

Everybody was now aware that this code was NOT a paper tiger.

This is sad, not for the person who has been expelled, but for the person who had to suffer inappropriate behavior.
This is good, not because someone had to report an inappropriate behavior, but because someone was able to report an inappropriate behavior and because the API Strat staff reacted promptly and efficiently.

Next time you attend an event, read the code of conduct and don’t be a jerk. Next time you get out of your home, don’t be a jerk, even if there’s no code of conduct.

Selective memory

Thusday 9:15 am. Main Stage. The show began. Here’s what stood out for me.

Consuming API is mainstream and you can make money out of it

Obviously we, API nerds, are accustomed to breath, eat, sleep and live API, but Mark O’Neil showed us that APIs are becoming maintream. They are so incredibily mainstream that anyone use them and therefore these APIs become a vector of shadow IT (for the better or the worse).
We are so focused on providing APIs, even if we want to provide good ones, that we don’t see that consuming API is more common than exposing them and that there’s still an entire business to create there: helping people to consume API at large scale.

API Business Strategy and Monetization

Consuming API is mainstream so providing API is more and more important. You may even, like Susan Danziger, face unexpected API challenges. Ziggio was a recrutment platform before becoming a video API service. They had to build a video recording component (with an API) and realize that it was a wonderful product. This product allowed Ziggio to turn to an API based model company and turn its competitor into customers.

Once you provide API, you’ll have to find the right monetization model. As Mark O’Neil and Susan Danziger stated: API monetization doesn’t just mean charging for API calls. Finding a good model is hard. For Ziggio, the success came from the Mickey Mouse model, based on how Disney was monetizing its licences.

Whatever the model you choose, allways give the means to let your customers know what the bill will be (with a simulator for instance).

Architecture

Architecture is not a matter of belief, it’s a matter of context and purpose. Erin McKean reminded us that in a very entertaining and insightful talk which showed us how the Wordnik architecture was being simplified. When designing architecture you MUST know the constraints to make the right decision. James Higginbotham also told us to step back from digital transformation focusing only on technology. We need to choose tools wisely with a purpose, a goal and not just because it’s cool and shining new (who said GraphQL and microservices?).

The future of API architecture’s scalability lies in event driven architecture instead of request driven architecture told us Mark O’Neil. But it’s mainstream present lies in managed service like AWS API Gateway and Lambda as told us Erin McKean: these solutions lower heavily the knowledge and expertise needed to handle scalability. In the last month zero time was spent on this new architecture, and it costs less money.

The future is dark for big API management solutions: Mark O’Neil told us that the microgateway , a small low-footprint, scriptable, API gateway in nginx or node.js is becoming mainstream.

Design & Governance

When you provide an API, you don’t do that just because. You do that hoping that people will use it. So don’t be a jerk: take care of what you provide and how you provide it.

My parts are showing?
C3PO

Do you know how your microwave oven works? Probably not. But, still, you can use it by using its simple interface which do not mirror its internal organization. This is the perfect example of an outside in design approach.

But the design road to hell is paved with good intentions. The desire of perfection will be hit by reality. As Matt Bernier tolds us: People will not care about a bad designed canonical REST API.

If you design API, listen to James Higginbotham “Consumers don’t care about what’s behind the API. Be outside in and not inside out” and Mark O’Neil “Don’t dump your internal data model on your mobile clients!” (who said GraphQL?).

And don’t dare to think that the outside in approach is only a technical matter or you may see a snarling Matthew Reinbold looking at you with fierce eyes. He reminded us that Conway’s law waits in the darkness like a sword of Damocles hanging upon your API design. Internal organization is different from external perception and mirroring it in an API may not be the best idea. James Higginbotham even urge enterprises to get rid of project based IT and embrace product based IT. Splitting resource on multiple teams or building separate APIs from each entity in a big group will not provide a unifed view and consistent, understandable and usable API.

Beyond the risk of having people NOT using your API, you may even loose customers because your API sucks. Amber Fallon asked us: “what will happen when a bank provides a terrible API which is used in a popular pfm (personal finance management) app with other banks API?”, customers may just switch to the bank offering the best experience with this pfm application.

You get it now. You have to take care of your design and do it the best way. So, as Jeremiah Lee told us: work HARD on API design so it will be easy to use on the client side.

DX = SPEC + DOC + LIB

API design is only an ingredient in the developer experience (DX) recipe. Take care of all aspects of API consuming. As Matt Bernier explained, developer experience is a combination of API specification documentation and client libraries.

Once designed the hard work is not over. Your API WILL evolve. You WILL introduce breaking changes. You’ll have to find an incentive to make your consumers move to the new version of your API, especially for technical upgrades.Jeremiah Lee showed us that when migrating from Oauth1 to Oauth2, introducing new functionnalities only in the Oauth2 version of the Fitbit API was a successful strategy.

Even if developers suck at designing API (just kidding), some of your dev may have good ideas. At Fitbit, developers can submit API modification by making a pull request on an OpenAPI specification.

Law and Order

Journalist by trade, lawyer by training, Sarah Jeong bringed us the story of the epic Oracle vs Google battle with her amazing talk You wouldn’t reimplement an API.

This appalling and insightful story reminded us that explaining what is an API to non technical people (the jury), especially in a trial, is quite a challenge. Did the jury understand? Probably not. They may have abandoned after trying to read source code with notepad. Don’t get me wrong, the problem is not with the jury but with what they have faced.

Finally Google won… for the time being. But what are the consequences? Nobody knows.

You can read the full story in Sarah Jeong’s post In Oracle v. Google, a Nerd Subculture Is on Trial.

Chaos, opportunities and attention

Mike Amundsen unleashed a life-saving chaos upon us. He showed us how chaos saved Nintendo from financial ruin.

Alas, Radar Scope was not a hit in America. In fact, it sold only 1,000 units, leaving 2,000 arcade machines with very expensive hardware sitting in Nintendo’s warehouse. The implications were potentially devastating. Nintendo could either give up, and face financial ruin, or it could develop a conversion kit that would turn those cabinets into something marketable. The secret history of Donkey Kong by Travis Fahs

Hiroshi Yamauchi, CEO of Nintendo, chose to give the lead of this last chance project to a young and inexperienced Shigeru Miyamoto … the future creator of Super Mario. Miyamoto created of totally new type of game, Donkey Kong, that was a huge success. He broke all the existing video games rules because he was not aware of them.

Mike showed us also us we needed leaders who can maintain stability around chaos. Serendipity needs a fertile ground, we must create openness to enable new ideas. Opportunities will come from the people around us. On the contrary, asking for data and measurements is the best way to stop creative works.

On a more personal level, he told us that our life is like a lego box and not like a jigsaw that has only one way to get it right. We need to create whitespace for ourselves to think. When working on something, we need a break, we need to do something else to refuel our brain and free it. And Jeremiah Lee gave us this whitespace at API Strat! Before his talk he made all the room moving, jumping, running in place, yelling, refueling everyone.

Charles Ashley told us his story, how he came to create the Cultivating Coders Foundation. He reminded us that we shouldn’t take for granted our heavily connected life. In this world, even in developed countries, people still have to go to a library to have access to knowledge.

And opportunities heavily depend on what you can access. So he asked us: are you committed or interested?.

My friend, Kin Lane, the API Evangelist, captured the public attention with an unvarnished talk Drone Recovery In The Attention Economy. He shared with us his very personal story, leaving me thoughtful on my very existence. I urge you to read this story on the API Evangelist blog.

“Attention” is a noun, but it refers to an action and/or a state of being. Attention is a mental activity. An earnest activity – which I particularly like. Kin Lane

Pay attention to yourself, to your life, to your job, to your family, to the people around you.

People First

Friday 10pm. So there we were the last API nerds standing, having a long but last discussion before flying back home. All topics and items, weither technical or personnal, sticking in my selective memory have something in common. This last discussion was about this common denominator too.

People.

No single piece of technology is what truly matters, not even the API, it all depends on what I do with them, and how we empower (or hurt) humans with them. This is a human story. This is my story. It is not a technology story. It is my personal journey. The technology is just one of the tools in my toolbox. Kin Lane

When we do API (or anything), we must not think code first or API first. We must think people first. The people directly involved by our projects. What problem are we solving? Does our architecture/solution can be created and managed easily by people? Does our API/Service/Product is useable by people? People ARE what will make our projects succeed.

But we also need to think about the people beyond our projects. What do we do to help people around us? Are we committed?

So maybe in the future will we try to talk less about how we build APIs (but we still need to talk about it) and more about what we (try to) solve with them.

Thanks to all people involved, it was an awesome trip, it was an awesome conference.

See you at next API Strat.

Boston Library Photography by Cinzia Dosa Lauret