Что лучше: выпустить глючную фичу или вообще не выпустить эту фичу?

Убедитесь, что люди знают, что вы знаете, что есть проблемы. Что есть баги. И дайте им простой способ оставить отзыв.

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

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

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

Перфекционисты могут ответить «не делай этого».

Деловые люди могут ответить «сделай это».

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

Есть ли способ предоставить бета-версию 4-5 людям, которые запросили эту функцию? Затем, как только вы получите их отзывы, может быть ясно, какое решение принять.

Точно задокументируйте шаткость и отправьте ее.
Убедитесь, что пользователь, скорее всего, увидит и поймет вашу документацию о шаткости.

Вы даже можете обсудить это решение с пользователями, которые запросили эту функцию: проведите небольшое исследование рынка.

Если вы не можете исправить это сейчас, это не значит, что вы не сможете это сделать в будущем. Вещи меняются.

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

Отправляйте раньше, отправляйте часто, постоянный рефакторинг.

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

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

Я думаю, это зависит от ваших стандартов. Для меня код с ошибками не готов к работе, поэтому его не следует отправлять. Можно ли получить бета-версию со списком известных проблем, чтобы пользователи знали, чего ожидать при определенных условиях? Они получают выгоду от использования новых функций, но также знают, что они не идеальны (используйте это на свой страх и риск). Это может на какое-то время осчастливить тех 4 или 5 клиентов, которые запросили эту функцию, что даст вам больше времени на исправление ошибок (если возможно) и выпуск в производство позже для масс.

Просто некоторые мысли в зависимости от вашей ситуации.

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

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

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

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

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

Если спрос на функцию СЕЙЧАС, а не функцию, которая работает. Возможно, вам придется отправить.

Хотя в этой ситуации:

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

Если ошибки могут привести к смерти или потере файлов пользователей, не отправляйте их.

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

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

Если он ничего не ломает, почему бы не отправить его? Похоже, у вас хорошие отношения со своими клиентами, поэтому те, кто хочет получить эту функцию, будут счастливы получить ее, даже если она не полностью реализована, а тем, кто не хочет, все равно. Кроме того, вы получите много отзывов, чтобы улучшить его в следующем выпуске!

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

Это сводится к очень реальному выбору путей: является ли ошибка чем-то, что не работает должным образом, что не было частью предполагаемого поведения и дизайна? Или это ошибка, только если она не работает в соответствии с предполагаемым поведением?

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

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

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

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