У меня нет доступа к достоверным данным или фактам, поэтому я могу только предложить вам отдельные примеры, полученные из моих последних 20 лет в ИТ.
Я считаю, что существует большая разница между тем, как большинство разработчиков создают программное обеспечение сегодня, по сравнению с тем, что было 20 лет назад. Благодаря быстрому движению Agile, особенно за последние 5-6 лет, я увидел реальное изменение отношения на рабочем месте. Настолько, что качество того, что мы делаем, кажется, стремительно растет с каждым годом, и с каждым проектом, когда мы применяем уроки, которые мы извлекли из проекта в проект. Процессы Leaner в сочетании с акцентом на первоочередную разработку превратились из очень противоречивых в обычное явление. Настолько, что сегодня, когда вам не по душе Agile, вы вошли во многие компании, и вам повезет, если они не покажут вам дверь.
Так какое влияние это оказало. Прежде всего, я заметил, что проблемы часто выявляются гораздо раньше. Часто бывает, что если проблема не выглядит слишком большой, иногда ее можно приостановить на неопределенный срок. В редких случаях я видел, что ошибки, которые считались тривиальными, стали серьезными проблемами при их последующем рассмотрении, поскольку становится очевидной некоторая фундаментальная проблема, которая не рассматривалась в то время. Иногда это может привести к затяжному циклу исправлений, и это может быть в некоторой степени дорогостоящим, но эти затраты часто измеряются с точки зрения предоставления ресурсов и чаще с точки зрения влияния на отношения между заказчиком и разработчиком. Клиенты привыкли к этому гибкому мышлению, которое дает им результаты гораздо быстрее, чем в прежние времена, с высокой итеративной скоростью разработки и быстрым переходом между запросами и реализацией, поэтому они ожидают от нас многого. А что касается фактических ошибок, то время для исправления ошибки чаще всего значительно сокращается в результате наличия солидного набора тестов для поддержки изменений и способности создавать новые тесты, из которых можно получить представление и решения. к проблемам сообщили.
Таким образом, в целом, похоже, что общие усилия по исправлению ошибок были в большинстве случаев сокращены, если имеется надежный набор тестов и процедур, гарантирующих, что тестирование остается в центре внимания разработчика, но фактические затраты в некоторой степени частично сместился, по крайней мере, с реализации на другие сферы бизнеса, потому что в некоторых отношениях акцент также сместился с чистого спроса и предложения на управление взаимоотношениями.
Еще одна вещь, которая стала очевидной, это то, что наши интуитивные инстинкты несколько лет назад, которые предполагали, что быстрая Agile сокращает наши циклы обслуживания, были доказаны в некоторой степени как правильными, так и неправильными. Прямо в том смысле, что тщательное тестирование значительно облегчило отладку и исправление нашего кода, а также уменьшило общее количество ошибок, допущенных в производственном коде, и неверно в том смысле, что мы сейчас работаем усерднее, чтобы избежать необходимости поддерживать унаследованный код путем постоянного рефакторинга кода и совершенствования архитектуры, так что становится все реже, что нам необходимо разрабатывать новые продукты с нуля.
Итак, в конце концов, что это значит в отношении вопроса ОП? Что ж, это означает, что ответ на самом деле не такой резкий, как мы когда-то могли подумать. 15 лет назад я бы наверное ответил на вопрос как да, но теперь я чувствую, что более реалистично сказать, что на самом деле слишком сложно измерить эмпирически, потому что характер того, что мы делаем для разработки программного обеспечения, сильно изменился по сравнению с тем, когда мы впервые начали задавать себе вопрос ОП в то время. В некотором смысле, чем больше мы продвигаем наши методы и навыки как отрасль, тем дальше вопрос растет от окончательного «да» до такой степени, что я подозреваю, что через несколько лет мы будем говорить, что это не имеет значения когда мы исправляем ошибки, потому что наши тесты и процессы будут намного более надежными, что время исправления ошибок будет меньше зависеть от усилий по экономии наших бюджетов, и больше от приоритетов для удовлетворения потребностей наших клиентов, а относительная стоимость будет стать практически бессмысленным в контексте.
Но, как я уже сказал, это не веские доказательства, основанные на данных, а только мои наблюдения за последние несколько лет и моя интуиция, говорящая мне о том, что будет еще больше потрясающей мудрости, которая улучшит то, как мы делаем вещи.