By Bob Steagall
As programmers, we use APIs every day, whether it is at the library level, the subsystem level, or the individual component level. And yet, using many existing APIs is often an unsatisfying experience, for any number of reasons: poor documentation, confusing component interfaces, muddled abstractions, broken/missing functionality, etc.
So how can we distinguish between a good API and a bad API? More importantly, how can we make the argument to our managers that good APIs, whether obtained off-the-shelf or built in-house, are a prudent investment?
This talk seeks to discuss these questions and perhaps provide some answers. We’ll look at specific criteria for evaluating the goodness and/or badness of an API. We’ll cover the concepts of technical debt and software capital, and define a relationship between them and API goodness/badness. We’ll also discuss a simple iterative process for building APIs which can help avoid technical debt and increase software capital. Finally, we’ll cover some recommendations for doing evaluations, using the process in day-to-day work, and convincing management of your wisdom.
Advertisement
