How a change request can actually be a proof of concept for an API
Just another great chat with a colleague of mine about a recent development we are undertaking. We commissioned the development of an API to a development agency this API is intended to abstract certain services to a single interface in order to be able to swap services transparent to the applications using them.
Right in the middle of development we needed to do just that.
Usually change requests are something to avoid during development as they tend to make things more complicated to throw away already written code and make developers feel uneasy about the stability of the requirements.
Of course change requests happen all the time and particularly during development.
But in this case we needed to swap a service for another one for come contract reason and swapping services was one of the requirements of the API. So we knew to expect additional costs for only the service implementation and no further change to the rest of the API.
Call it a proof of concept. If swapping services is possible with little overhead even before the API is built we know that we will get what we ordered. If it didn’t allow this we would know now way before the deadline that there have been fundamental errors in the design.
It might be a healthy approach to change requirements for details in a project that are ordered to be flexible just to challenge the architecture and design. This might not fit all the time but if it does it will be a really cool reality check.