Почему программное обеспечение все еще выпускается с известными ошибками? [закрыто]

18

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

Почему? Почему проект с открытым исходным кодом или проект в целом будет выпущен с известными ошибками? Почему бы им не подождать, пока трекер ошибок не обнаружит 0 открытых ошибок?

TheLQ
источник
3
Пахнет дураком.
Работа
41
Покажите нам полезное программное обеспечение без ошибок.
Джоэл Этертон
13
Потому что время бесконечно, а люди нет?
Джо
7
Спасибо за этот пост, он рассмеялся ... Я не удивился, увидев, что тебе 18 лет в твоем профиле. : D Вы, очевидно, еще не работали с менеджерами программных команд .
Ям Маркович
7
Одна из наиболее распространенных причин: в этом выпуске исправлены критические ошибки или ошибки, которые влияют на реальных клиентов, и, по крайней мере, насколько известно, не добавляются новые ошибки, которые могут это сделать.
Дэвид Шварц

Ответы:

41

Любое количество причин, в том числе:

  1. Компания взяла на себя обязательство по выпуску базы пользователей в определенное время
  2. Ошибки не были критически важными или даже серьезными
  3. Разработка новых функций рассматривалась как более важная (правильно или нет)

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

eykanal
источник
24
+1, но я хочу добавить: 4) Странные неповторимые, казалось бы, единовременные ошибки вхождения, которые регистрирует QA. Такие вещи следует отслеживать, но они могли быть результатом необъяснимого простоя сети, незапланированного простоя среды или обеспечения качества просто потому, что просто не предоставили достаточно информации, чтобы ее можно было отладить. 5) Незначительные ошибки, для решения которых требуется непропорциональное количество усилий, например Полный рефакторинг конкретного модуля.
maple_shaft
4
Хороший комментарий, мелкие ошибки, которые требуют огромных усилий по рефакторингу для устранения, как правило, остаются без внимания.
эйканал
5
Может также быть, что ошибки не рассматривались компанией как критически важные или серьезные. Клиенты могут сказать иначе, но вы знаете только, когда ваши клиенты говорят вам.
joshin4colours
37

Потому что программное обеспечение с ошибкой лучше, чем вообще никакого программного обеспечения.
По той же причине:

  • Транспортные компании стараются составлять графики, хотя всегда есть задержки.
  • Фармацевтические компании продают лекарства с известными (и в основном задокументированными) побочными эффектами.
  • Школы во всем мире преподают ньютоновскую физику, хотя она имеет известные ограничения.

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

Или сказать это словами Вольтера: «Le mieux est l'ennemi du bien».

back2dos
источник
22

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

Томас Оуэнс
источник
1
Я хотел бы отметить, что, очевидно, если ваше программное обеспечение полно ошибок, влияние может быть не выгодно;)
Matthieu M.
7

все сводится к анализу затрат и выгод. С каждым исправлением ошибки связана определенная стоимость (человеко-часы на исправление, риск внесения дополнительных изменений в код за X дней до выпуска ...). В то же время, каждое исправление ошибки явно приносит дополнительную ценность с точки зрения дополнительных возможностей, удобства использования и т. Д.

Итак, вот вопрос, с которым сталкивается каждая команда разработчиков при создании релиза: 1) стоит ли исправлять ошибку #i, учитывая стоимость и дополнительное значение, и 2) повторить для всех открытых ошибок от i = 0 до N.

Имейте в виду, что программный продукт, который не выпущен, не имеет значения для кого-либо. Программный продукт, который имеет 200 выдающихся ошибок, но имеет 90% работоспособности, имеет значение для всех людей, которые довольны тем, что работает во время выпуска.

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

DXM
источник
6

В большом проекте вы никогда не перестанете находить ошибки. Если бы вам пришлось ждать, пока все ошибки не будут исправлены, а исправления исправлены, вы никогда не отпустите их.

Также обратите внимание, что не все ошибки являются внутренними. Каждая программа является частью сложной сети другого программного обеспечения, и изменения в другом месте могут проявляться как «ошибки» в вашем программном обеспечении. Вы не можете остановить мир.

ddyer
источник
С этим связан тот факт, что каждое исправление ошибки создает возможность вносить в продукт новые ошибки, которые могут быть более серьезными, чем исходная ошибка.
Малахи
4

В дополнение ко многим хорошим ответам, иногда идет гонка на рынок с новым продуктом. Если вы считаете, что можете получить большую долю рынка даже при открытых 15% (или некотором другом количестве) некритических дефектов, возможно, стоит выпустить продукт, чтобы получить преимущество над конкурентами.

FrustratedWithFormsDesigner
источник
2

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

DeadMG
источник
2

Потенциальные ответы:

  • Крайне маловероятно, чтобы кто-либо столкнулся с ошибкой.
  • Есть обходные пути для ошибок.
  • Программное обеспечение должно быть выпущено когда-нибудь, и совершенство вряд ли будет достигнуто.
Джон Фишер
источник
2

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

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

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

Менее оптимистично на мой взгляд, возможно, потому, что разработчики ленивы?

Также помните, что в сообществах с открытым исходным кодом, как правило, «кто» хочет принимать на себя какие запросы об ошибках / функциях / проблемах - возможно, никто не хочет иметь дело с проблемами, которые присутствуют из-за более крупных проблем, стоящих за ними.

Даррен Нолан
источник
1

В простейшем программном тесте:

if (management->perceived_cost_to_fix > management->perceived_benefit_release_now) {
    release;
}

Все всегда является компромиссом, будь то исправление ошибок, время / пространство / память или безопасность / удобство использования. Подумайте о расчете компромисса, который был сделан. Вы можете не согласиться с этим, но у вас проблемы, если вы этого не понимаете.

Кроме того, подумайте об этих вычислениях в виде кривой колокола ... некоторые люди будут делать очень плохие с обеих сторон. Посмотрите Duke Nukem Forever для одного конца кривой.

Джефф Ферланд
источник