2 minutes
Schedules of others
Imagine you’re on a development project which relies heavily on a third party software. Then, out of nowhere a new version is released which changes the function(call)s in a way that your software breaks. Or the end of life of this code is announced surprisingly. Actually, there is very little you can do to avoid such situations. But the shock can be mitigated somewhat by being well informed and up to date with the press releases of the software provider. Usually, there is either a mailing list or a syndication feed with important release informations. There are probably also some rumor sites or private blogs of developers which could give away some hints beforehand. Or even advises how to handle the situation. Now being well informed doesn’t solve your problem: the project is at risk in both scenarios. So the development process has to stop and some emergency plan has to take effect. First, the impact has to be quantified. Which parts of the project are affected? (All others can go back to work) Second, decide what has to be done. Is it feasible to adjust to this new situation in the current state of the project? Do some parts of the project need a code review? Has this to be communicated to the public? Third, test against the above points and reiterate if necessary. Or close the incident and get back to normal work. So note that third party software provider, especially the commercial ones, have their own schedule.