Тут в комментах было большое обсуждение — на что опирается вообще дисциплина создания программ, и есть ли там научные основания.

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

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

Наверняка вы его видели, и авторы приводят разные оценки по стоимости исправления ошибки на этапе сбора требований и на этапе эксплуатации — то в 100 раз больше, то даже в 1000. Мне стало интересно, какие за этим эмпирические данные.

Говоря коротко: крайне сомнительные.

Впервые этот график появился в статье Барри Боэма в 1976 году. Опирается он на данные Боема из проектов компаний GTE, TRW и IBM. В 1981 Боэм в книге "Экономика программной инженерии", повторил график и добавил ещё несколько точек. Данные, на которых он основывался, практически недоступны, но есть публикации примерно того же времени: большое исследование TRW, в котором данные по скорости исправления ошибок показывают нечто другое — ошибки с высоким приоритетом исправляются за 4-10 дней, вне зависимости от фазы, на которой они найдены (дольше всего, 10 дней — на стадии валидации; в операционном окружении — 4 дня), ошибки среднего приоритета — за 10-19 дней, низкого — от 8 до 17. То есть, разница никак не в десятки раз, и зависит не от фазы, а от приоритета.

Другие его данные ("для небольших проектов") — это две команды вчерашних студентов, и их реальный график выглядит не как экспонента, а как зубцы — похоже, они начинали интенсивно работать после каждой фазы приемки (исправлять выявленные ошибки), а между ними пинали балду. Боем оставил только несколько точек интенсивного исправления ошибок, сравнив их с самым низким уровнем производительности, а все "зубцы" выкинул. Трудозатраты на исправление ошибок на этапе требований он, похоже, просто выдумал. "Ну, пусть будет примерно в 10 раз меньше" (в TRW эти усилия просто не измеряли).

Дальше начинается увлекательная история многолетних подтасовок: перерисовывания графиков, смены точек отсчета, переключение между абсолютными и относительными единицами измерений и обобщений от "в некоторых проектах начала 1970-х годов мы можем видеть разброс в усилиях по исправлению ошибок от -2 до 1000 раз", до "во всех проектах всегда стоимость исправления ошибки в операционной среде в 100 раз выше, чем на этапе требований", цитирование цитат, вносящих всё большие и большие искажения, прямого игнорирования данных и так далее. Подробно это описано в книге "Лепреконы программной инженерии" Лорена Боссавита, где вскрывается ещё несколько распространенных мифов про разработку.

Вплоть до книги Кента Бека, в которой он цитирует "своего профессора, нарисовавшего график на доске", и его собственное предположение, что уж в XP-то ничего подобного не будет. В каком-то смысле, график стоило выдумать, чтобы движению agile было, с чем бороться. Говоря шире — чуть ли не все усилия по придумыванию новых методов разработки направлены на преодоление несуществующего или кратно преувеличенного эффекта.

При этом никто даже не пытался воспроизвести исследования 1970-х годов.

Самое обширное, чуть ли не единственное и строго выверенное с точки зрения современных стандартов исследование охватывает 171 проект с 2006 по 2014 годы; удобно, что в этих проектах производился точный подсчет времени. В результате не обнаружено ничего: усилия по исправлению дефекта практически никак не зависят ни от времени его внесения, ни от времени его исправления. Единственные всплески — на упущенных на стадии требований дефектах, дотянувшихся до интеграционных и нагрузочных тестов, но и там в худшем случае коэффициент x3.

Звучит логично, на самом деле — с чего бы им быть дороже в исправлении? У нас не 1970 год, мы не пишем на COBOL'е и FORTRAN'е, не вводим код на перфокартах и не строим монолитные архитектуры высокой связности. Вспомните свои проекты, какая картина более реалистичная?