В опубликованной только что на sapland статье "Классификация отраслевых решений" есть слабое место, за которое конечно сразу зацепился внимательный читатель. Деля разработки на лабораторные и полевые я ни чего не доказывая объявил, что лабораторные лучше. Пришло время держать ответ.

Чуть раньше, в статье "Замкнутый цикл производства пустых фантиков" я рассказывал про проблемы как раз полевого отраслевого решения (правда термин "полевое" тогда еще отсутствовал). Держа это в голове и сосредоточившись на разработке классификаций, я упустил из виду доказательство. Исправляюсь:

Вообще то ИТ системы не так сложны как это кажется. В их основе лежит арифметика с минимальными вкраплениями теории множеств (структуры баз данных). Написанный с нуля код (лабораторный вариант) с большой вероятностью вполне пригоден к делу, к тому же его гораздо легче развивать. Полевой вариант создавался как развитие базовой архитектуры заплатками. Доработки (заплатки) при новом внедрении будут в обоих случаях, но в лабораторном варианте – это заплатки на девственно чистый код, а в полевом варианте это заплатка на заплатке (см. статью про рынок пустых фантиков)...

Кстати, при разработке лабораторного варианта Интегратор походит к вопросу более ответственно. В полевом варианте вопрос выделения кода порой откладывается на потом, ведь все что работает можно показать на первом клиенте. У тех кто работал в лаборатории такой привилегии нет – им надо создать работающую демо версию. Есть конечно шанс, что эта версия будет чистой бутафорией, но этот шанс не больше чем с полевым решение (код не отделенный от прошлого проекта – бутафория).

Ну и последняя деталь - это сроки. В лабораторном проекте обычно сроки являются менее жесткими (Интегратор еще не связан контрактом) и есть время разработать качественную архитектуру решения.