Stable Interfaces – any good?

Facebook

Twitter

Linkedin

I once worked in a rather large project, about 1000 persons. There are many stories about that project but the one that I’m thinking of now is that we loved to say "stable interface, we must have stable interfaces".

Now, stable means not changing which means nothing gets better. So why would anyone want stable interfaces? And what should we say about the opposite, "unstable"?

Stable interfaces is a cornerstone in tactics for modifiability, so how do stability and modifiability go hand in hand?

Do you see my finger?

No, I am not doing a rude gesture, don’t worry. The fingers, part of the hand, are so powerful because, among other things, they bend a specific points, the joints.

So a finger is flexible, to a certain extent, which makes it more powerful than if it could bend any imaginable way.

The joints of a finger are the stable interfaces in your system’s architecture. E.g. we want to modify the system by adding new modules in runtime. So we define plug-in interfaces that the modules adheres to and uses for interacting with the rest of the system.

Those interfaces must be carefully designed as we don’t want to change them. Should we change a plug-in interface, every module would have to be rewritten and retested.

So some interfaces really need to be stable. But other interfaces we change all the time. Every class in your code has an interface so you can’t do much without changing that. It will affect other parts of the code but thanks to type safe languages and automatically running tests, it is not as bad as it used to be.

Bottom line. Some interfaces are part of an architectural strategy and need to be stable therefore. But most of the interfaces really need to be on a roll.