Per Lundholm

Per Lundholm

Everyday Software Development

Stable Interfaces – any good?

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.

Requirements Specification is Waste

So why do I say that requirements specifications are waste? After all, I’ve been trying to follow them for more than 25 years. But I never did that well. Sure, I think I understood the business value and created that, but it has been despite the specification.

What defines a system, besides itself, is the test cases. If the test cases are not running without manual intervention, the test protocol is needed as well. But now we are drifting into the fog of documentation.

There is no waste trying to find the requirements, it is the specification that tries to get so formal, that becomes the waste. When you search for requirements, you search for business value. But when you try to write a really good requirements specification, you get so formal, it almost like writing the code.

As I said, I’ve been around for a while. There have been so many attempts to find a way to express requirements in ways that can not be misunderstood and even be executable. But I will refrain from that history lesson.

Again, the point is that the requirements specification is waste. The spec as we know it, I mean.

If the requirements specification is waste, how that does this affect bug reports? I say, they are waste too.

At least, when the bug report is written by a tester that compares the outcome of a test case with the requirements specification. Since the latter is waste, so is the bug report.

You don’t need bug reports from your tester, you only need to know which test case that failed.

So all we have are our user stories (User stories are not use cases and are not requirements, they are not formal enough), which we use to discuss and later throw away, the code and the test cases.

That is all. The rest is waste, unless there is other value to it, such as a design guideline that really helps or an overview of the system architecture that really helps understanding.