Давеча позволил себе немного пожаловаться в твиттер:

Небольшое наблюдение за окружающей средой: возможно, мы (разработчики) недооцениваем, насколько часто мы ошибаемся при разработке взаимодействия распределённых систем.

Пускай у разработчика есть система А и система B. Они каким-то образом друг с другом взаимодействуют. И в один прекрасный момент возникает необходимость что-то поменять в одной из этих систем (пускай, A → A’).

Окей, говорит себе разработчик, тыжпрограммист! Система A меняется, значит, надо поменять и систему B, чтобы она знала про эти изменения. Берёт и адаптирует систему B к новым изменениям (B → B’), и думает, что молодец.

А затем, в продакшене, оказывается, что системы могут обновляться по отдельности, и наша система A’ встаёт рядом с необновлённой B. Или, наоборот, B’ пытается ужиться со старой A.

И никто за разработчика не подумал, что же будет в таком случае. А может быть что угодно. Потому что новый способ работы далеко не всегда бывает совместим со старым. Не совпадают протоколы, меняются опции вызова, формат хранения данных…

И это, разумеется, приводит к появлению самых разнообразных отказов и фейлов, про которые никто не подумал заранее.

Мораль у сказа до тупости простая: разработка ПО - это не та область деятельности, где годится применять экономию мышления, столь любимую нашим ленивым мозгом. На любое изменение полезно смотреть не только в статике (“как есть сейчас” vs. “как должно быть”), но и в динамике (“как пройти из A в A’ и ничего не сломать по дороге”). Можно называть этот подход хоть “темпоральной логикой” (по определению: учёт причинно-следственных связей в условиях времени), хоть системным анализом, хоть continuous delivery, хоть горшком - но только в печку не ставить не забывать.