Shipping API Under Time Pressure
March 23, 2019
When shipping API under time pressure, you may be tempted to reach for the most expedient way to get your feature out on time. Here are some strategies to avoid getting caught in a tangle of future technical debt. All this advice is based on buying yourself time post-release (or kicking the can down the road, if you prefer), but they sure do work.
Have a vague idea of what an ideal API might look like in the far future. Make sure what you release this year doesn’t make it hard to approach that ideal later.
Name your API very specifically (
VeryParticularWidgetBehavior, instead of
WidgetBehavior), to allow for future evolution that address more general problems in its domain.
Don’t add dependencies on other libraries just because you can “leverage” (abuse) otherwise unrelated chunks of their existing API. Boilerplate duplication is often better than adding another dependency. Library dependencies will outlive your API.
Stick with established patterns. Resist the temptation to add surprising relationships for the sake of expediency.
If your API must be shipped in a compromised state, minimize its reach. If it turns out to be bad, you will be thankful that it doesn’t have tentacles in the rest of your API.