When Good API Design is a Waste of Time
The idea that good design is essential to building great products and services has become a truism in our industry. Most of us intuitively understand the idea that expending effort on the design of our code, system architecture and APIs will payoff after implementation. I’m certainly a big believer in the power of good design for the API space, but I wanted to explore a situation where a design focus might not be necessary.
Consider the case of a small business offering a cloud-based service product for a niche market. If this business chose to invest in a well-designed, developer-centric API, at a minimum they could expect:
- A reduced learning curve for developers consuming the interface
- A reduction in troubleshooting time
- Increased interest from their developer community
For most audiences, these are goals worth achieving. Indeed, this is why we emphasize good design for APIs in the first place – the benefits fit remarkably well with the main reasons for embarking on an API strategy: reduced cost and increased adoption.
But, in my conversations with connectivity professionals from larger organizations, it is apparent that not all service vendors see the value in investing in this type of design effort. Developers and architects are bursting with tales of forced integration with service providers who have simply thrown an ugly or barely functioning interface on top of core component. It is in these scenarios that we hear about laughable attempts at implement whichever API styles and features are in fashion. ‘REST’ and ‘security’ become sales-worthy buzzwords that don’t live up to their promise when developers get their hands on the actual interface when real project work commences.
In the majority of these cases, technical teams have very little say during the procurement process of outsourced and cloud-based services. In effect, these API providers don’t need to design for their developer audience because they aren’t critical to succeeding. For many years a sound strategy for selling cloud-based products has been to sidestep technical teams and engage directly with the business. It’s frustrating that technology teams are often still left with the responsibility for reducing integration costs regardless of the lack of sophistication in the APIs that they are tasked with connecting to.
Thankfully, the wealth of knowledge and connectivity products in the enterprise space allows these teams to reduce the impact of bad design on the overall project and organization. Components such as API proxies can be used not only to build a facade for APIs that are being exposed, but also to provide abstraction for services that are being consumed. In essence, the design burden can shift from the service provider, to the enterprise developer who wraps a poorly designed interface in a more consumable, developer-friendly API for the rest of the organization to use.
As a whole, the scenario makes sense. Well designed products are based in part a designer’s empathy for their users. Good design involves perceiving a product from a user’s view point along with an understanding of the impact that design decisions will have on the user base. However, an organization that builds an API as an afterthought for developers, who are only viewed as a means to an end, will likely produce a poor API.
Ultimately, building a technology business based on developer apathy is a bad idea. The industry shift towards API product based integration is empowering technology teams at all levels and services that continue to ignore the needs of their developers will eventually be ousted from the market. In short, good design is only a waste of time when you don’t care about your users. If in fact you do care about the developers who will be using your API product, then you need to invest in designing your API with their point of view in mind.