Микроконтроллеры

А вы хорошо копнули. У него (и у меня) под "абстракциями" понимается не универсальный мыслительный прием, а вполне конкретные конструкции в виде библиотек или просто прослоек в коде. Как вы верно заметили, аналог редуктора или клино-ременной передачи, в механизме. Давайте назовем это "прослойками". 

Проблема, обозначенная Спольски, вовсе не в том что у сложной системы "больше шансов",

а в том, что ВСЕ прослойки имеют скрытые, неизвестные на этапе проектирования, ограничения.

И они слишком дёшево даются программистам.

Ни одному механику в жизни не придет в голову поставить в механизм ЛИШНИЙ редуктор,

а для программистов это поощряемая норма.

В жизни это регулярно выстреливает ситуациями, когда очередное мелкое "пожелание" заказчика НЕВОЗМОЖНО реализовать.

Причем не по каким-то фундаментальным причинам, а потому что тот или иной слой ПО содержит прослойку, неспособную пропустить

необходимую функциональность.

Приведенный им пример: работа с удалённым файлом по сети и ситуация пропадания связи в произвольный момент времени.

Естественно, драйвер сети знает о пропадании связи и прикладное ПО вполне могло бы отреагировать как-то осмысленно, но между ними

находится прослойка, в которой просто нет механизма передачи этой информации.

Причем добавить его практически невозможно. Поломается совсем все!

Или пример от меня: Предположим вы автор прикладного ПО, использующего готовую библиотеку Profinet.

Библиотека закрытая, но хорошая - передали номер ком-порта и все работает.

И тут вы ставите в комп мультипортовку, в которой порты называются не "COM1...COM4", а вовсе даже "AUX-A...AUX-F".

Ненуачо?! Драйвер мультипортовки в винде отлично понимает что с ними делать.

А библиотека - нет.

Как вам такой примерчик?