It's OK for a one-man-show project, or for a project developed by a compact team, where all members meet in a kitchen every day. In such small teams, synchronization between developers is almost instant, as all people share the same common knowledge about all code/product features.

As the development team starts to grow, team splits up into several ones - they may be all developer teams, some of them may be on-site customer support teams. It's even worse if business partners start to integrate with the product - another teams crawl in.

Another axis are bugfix releases developed in parallel with the mainline or some customized forks; with continuously changing core, such parallel development is very hard, and it is yet harder to integrate the parallel branches back into the main product line to exploit the synergies.

Here starts the need for maintaining API, changelogs for releases, migration guides, compatibility, etc. Developers in these teams primarily communicate within the team - and sync between all parties becomes more and more inappropriate and time consuming. The more the individual team's schedule, task flow, or management is separated, the more the bulletproof API interfaces are needed.

So a short summary: If you are alone on a project, or a very small and compact team, don't bother with APIs. If you are suffering high fluctuation, or your team is larger, separated into groups, different product lines, etc, DO invest into building a solid API-level interfaces. The costs will repay back soon.

Regarding the InfoQ post I must say that reusable libraries and modules in our area is crucial. Coding everything from scratch got us into the position where we just started to be less competitive to our rivals. Even when making highly customized software according to customer requirements reusing things that could be reused is very important for keeping costs at the level customer is willing to pay.

That's my experience.

But even in this case you can simply check how your colleagues are using the API and do your changes accordingly. That's the main difference between inhouse APi and public API. In public API you have no idea how it is used so you have to be much more defensive.

Interesting point of view on this subject has been published recently.

"I’d like to be flexible, I want to be able to fix my mistakes as fast as possible, I’d like to change my design quite often, I do not want to maintain backward compatibility. I do not have to."

Every programmer wants that. Me too - it means that you have complete freedom while extending or updating your existing code. And everyone wants to be free. I guess Jarda Tulach too.

But there you go. Sometimes there comes time, when other programmers start suffering from your freedom. They start to complain that you force them to adapt and repair their code again and again. And that's a signal, that you are no more doing PI but an API.

It reminds me Czech saying: the freedom of one ends there, where the freedom of another starts. And API is just representation of such border between freedoms.

This situation can happen to anybody - even you. Never say never.

So enjoy your freedom, it will last till somebody starts to beat you in the head.