Two sides to every story

Every truth has two sides; it is as well to look at both, before we commit ourselves to either.”

As the old saying goes, there are two sides to every story. Equally, there are two sides to every OSS interface (or possibly more if you including middleware, etc). Each side of the interface tends to be documented, specified, etc… often ad finitum it seems.

That’s all great, because both sides get a better understanding of what they need to do.

However, my perspective is that no matter how long you discuss the details, there will always be fine details that are missed or slightly misaligned that only get found when actually integrating. Because of this, my theory is that less time should go into documenting the finer details and more time should be allocated overcoming them in shake-out.

The other thing I find interesting is that both sides will often plan their testing in isolation at first. Rather than collaborating on end-to-end tests cases and underpinning data sets, it’s a little bit easier for each side of the interface to be tested separately before shake-out testing begins. I figure that the earlier the alignment happens, the more likely that discrepancies will be identified earlier rather than the deployment phase.

….. Then there’s the case where one interface is fixed (eg an equipment or EMS or NMS, where the vendor builds it and rarely updates, especially not on a customer by customer basis). But that’s a story for another day.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions


Most Recent Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.