щодо принципу Open/Closed:
Ви пишете, що код класу має залишатись незмінним. Власне, це вимога застарілого принципу Меєра, щоб спростити і пришвидшити внесення змін в умовах, коли неможливі належні тестування і перевірка. Одночасно він додає зайвий рівень наслідування і суперечить принципу інкапсуляції, який допускає і заохочує заміну реалізації класу при потребі.
Сучасний принцип Мартіна вимагає використання абстрактних типів (інтерфейсів) і збереження контракту класу, а не його коду.
stackify.com/...​gn-open-closed-principle
«It uses interfaces instead of superclasses to allow different implementations which you can easily substitute without changing the code that uses them. The interfaces are closed for modifications, and you can provide new implementations to extend the functionality of your software.»

спасибо. короткая статья, но очень полезная и насыщенная важными наблюдениями.

гарна стаття.
неодмінно варто повернутись і перечитати ще раз.
стисло, ясно і зрозуміло викладено багатий матеріал.
дякую!

«Мой любимый вопрос на собеседовании „Чем бы вы занимались, если бы не нужно было зарабатывать на жизнь? Давайте помечтаем. Например, вы выиграли сто миллионов долларов“»
если я правильно понял, вы просите кандидата довериться вам, пофантазировать и представить себя в маловероятной ситуации, в которой он никогда не был и в которую он вряд ли когда-нибудь попадёт, а затем втайне от него пытаетесь интерпретировать выдуманный для такой гипотетической ситуации ответ. никто не раскрывает кандидату ни мотивов и не требует от него пояснений.
я надеюсь, у вас всегда большой запас кандидатов, напрочь лишённых губительных мечтаний о заманчивых далях и алых парусах, которые мешают выполнять тяжёлую монотонную работу и приводят к профессиональному выгоранию.

«На співбесідах ми аналізуємо як хард скілз, так і софт. Тому важливо перевіряти людину на адекватність і почуття гумору.»
по-перше, жарти доречні між рівноправними співрозмовниками в звичайній ситуації. наприклад, між близько знайомими колегами по роботі. по-друге, той жарт був невдалий, бо медичну допомогу мають право надавати лише кваліфіковані фахівці.

Интересный, честный и самокритичный рассказ.
Да, конечно, бизнес вправе приобрести на рынке уже готовый продукт, чтобы не тратить время и усилия на его разработку. Вот только такого приемлемого по цене предложения на рынке, очевидно, не было. И если уж заказчик желал и сэкономить, и получить эксклюзивные права на программный продукт, который стал бы информационным продолжением предприятия и позволил бы получить дополнительные конкурентные преимущества, стоило бы проявить больше заинтересованности и включиться в качестве полноценного участника процесса его разработки.
Для этого нужно было начать доверять разработчику, позволить ему общаться с непосредственными исполнителями, чтобы получать от них своевременную и ценную обратную связь. Быстрое появление базовой функциональности и начало её использования, частые выпуски обновлений и регулярное устранение замечаний, постепенное устойчивое расширение сферы использование продукта позволили бы успешно завершить работу.
К сожалению, мы не имели возможности услышать противоположную сторону. Наверное, бизнес-аналитик плохо ориентировался в предметной области. Но вряд ли можно сделать верный анализ бизнес-процессов предприятия на основе общей информации о корпоративной культуре, инвестициях и финансовом положении заказчика, случайных консультаций у коллег, субъективных отзывов сотрудников или изучением конкурентов. Вряд ли заказчику понравилось бы несогласованное использование информации от инсайдеров. И, конечно, ничто никогда не сможет компенсировать откровенный саботаж и непонимание сотрудников заказчика.

скорее всего, полное отсутствие контроля и отказ от ответственности со стороны заказчика, очковтирательство со стороны исполнителя. т.е. организационные проблемы. технические решения (платформа, язык, парадигма), наверное, не играли никакой роли