The Seven Righteous Fights: Extensibility

This is the third fight in my series The Seven Righteous Fights. For an introduction, see The Seven Righteous Fights: Overview.

What can you do that would make your product more extensible, more configurable, easier to put into the ecosystem you are trying to serve? I always explain APIs as a sort of Lego connector between a given piece of software or data, and anything else someone chooses to stick on it. Make your APIs standard and DOCUMENT THEM WELL.

Lego_ball

You can connect anything to this.

What makes you so sure this API will always be internal?

On a recent contract, we started to create APIs for our internal services. We bodged them together in a really ugly way, with names that only made sense internally, based on dead products we didn’t release. I argued that it would be better to build them correctly, but obviously I didn’t argue enough, and when I left, they were having to rewrite the whole API call structure because an external client had requested access it.

Don’t make future-you mad.

Make future-you happy by designing your product to consume APIs. That way when you get a sudden request to provide APIs for a customer, you’ll know that they work because you’ve used them yourself.


This blog post is part 3 of my Seven Fights series. You can hear me give this talk TOMORROW at The Lead Developer in London (June 22-24) or at SpringOne Platform (August 1-4) or Abstractions (August 18-20).