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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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