Chasing a Constantly Changing API
By Michael Sheeley
I was once waist deep into a development effort when a partnering development team informed us that they where changing their API again. The component we were developing depended on their components for data and capabilities. We had spent time interfacing with their component. We had been careful enough to isolate the interface to their API by creating a façade. This way, the two components were decoupled as much as possible and our component was somewhat isolated from future changes to the partners API.
Our partner was already changing their interface. Not a problem, right? The façade is the only subcomponent affected by this change. An engineer spends a few days reworking it and we move on. It’s that easy right? Well, no.
When this happens you need to make sure you find out why their interface is changing. Ask your partner why this change has been made and why this change was not thought of originally. If they do not have solid reasons for this, then be assured that their API will soon change again and you will find your team spending another couple of days updating the façade. I have seen this situation play out many times. Each time the partner swears that “this is the final change to the API” only to have it change again a week later.
Yes, the façade acts as a buffer to new changes but changing the façade still requires work. And no façade is completely perfect. Some changes might still bleed into other subcomponents causing many other needed changes. In fact, the more you need to update the façade, the greater the chance that the changes will effect all the subcomponents who utilize the façade.
In many situations you have no control over your partner’s development practices. It is important to first identify when you may be dealing with an unstable API. Once you have identified the API as unstable, you have a few options other than using up all your resources chasing it.
- Hold off on making the changes. Wait a few weeks before updating your façade to their latest API. You might also be able to wait till the end of the development effort to make the update. This way, you will skip a few interim API changes. I do have a word of caution on this. Make sure you’re not ignoring their changes; only skip the updates to your code. You want to make sure their changes do not drastically change or remove the needed data or functionalities you require from them. If you wait till the end of development, it might be too late to address the problem.
Send you partner your façade. Many partners will pushback on this. They might see this as more work for them, but it might actually save time for both of you. They have a better understanding of the new API and it will be a quicker change for them to make. They already know what changed in the API and why, thus cutting down on cross team meetings and emails.
Make sure you identify their unstable API as a risk to the project as early as possible. Assess your options; determine if your schedule, budget, or scope for the project is at risk. Chasing a changing API never seems like a big deal to the project until it is too late. If it is not identified and dealt with early then it will put the whole project at risk for failure.
Michael Sheeley is an entrepreneur in the software industry. His experiences range for starting businesses to developing new software as a software engineer. His current position is at BAE Systems developing and enhancing new technologies for the armed forces. Michael’s blog can be found at http://www.sheeleytech.com/.