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.
In Google Reader, when I read about a person that had been in a 1000-person project, my first reaction was “Hm… that’s about the size of AXE-N”. Hehe.
And you are totally right, of course. That mantra about stable interfaces was obviously true then, 15 years ago. We know better now. Changing API:s are no big deal if done well, especially inside a company.
I agree too.
Actually, inside a module – I don’t like to see too many interface classes at all.
Unless they are meant as interfaces to the module itself.