Выбор технологий под проект

Фредерик Брукс в своём Мифическом человеко-месяце разбирает вопросы размера команды, выполняющей сложный проект. Один из важных выводов: добавление новых членов в команду может ухудшать общую производительность и отодвигать сроки проекта. Эффект проявляется сильнее если в проекте уже есть накопленный дефицит времени и ресурсов, а также на поздних стадиях проекта.

Аналогичная закономерность справедлива и для используемымых технологий. Любая технология требует времени и затрат на её внедрение, а также минимальный размер инфраструктуры, на котором технология полезна. Затраты на внедрения хорошо масштабируемой технологии (а именно таким и надо отдавать предпочтение) обычно сильно убывают с размером инфраструктуры, но в самом начале они значительны. Отсюда выводы:

  1. Для небольшой инфраструктуры лучше избегать ресурсоёмких технологий, какими бы хорошими, модными и полезными они ни были
  2. Когда использовать технологию становится целесообразно обычно лучше её внедрять на новой отдельной инфраструктуре, а не вносить изменения в рабочую старую.

Вроде бы вполне очевидные выводы, но постоянно встречаются примеры использования технологий "на вырост" или "потому, что крупный конкурент использует и мы тоже будем". Разные CRM, фреймворки, дорогое железо под них, узкоспециализированное ПО — если не используется по назначению, то становится обузой компании и отнимает ресурсы.

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