Об ошибках и парадоксе скорости разработки

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

Где же парадокс?

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

Всегда ли это так? Что? Не всегда?

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

Условия переменчивости среды

«Ну и словосочетание» — скажете вы, и в принципе будете правы. Что я имею ввиду?
Простой пример из жизни: вы опытный разработчик, привыкли создавать и отлаживать небольшие приложения сам, практически с нуля. Внезапно, руководство решает, что необходимо повысить скорость разработки программного обеспечения, и создает из вас и другого программиста команду. Среда сменилась — раньше вы писали код в одиночку, а теперь работа разделена.

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

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

Другой пример

Или вот другой пример: система готова, и вам поручают переделать какие-то ее части, причем не всегда выставляя точные и адекватные требования.
Среда изменилась: вы уже изменяете не свой код, а общий. Вы быстро все переделываете, но не обращаете внимания на мелочи и не тестируя систему в целом. Затем появляются новые и новые требования, которые оказываются вашими багами. Время растет, сроки прошли, дедлайн каждый день.
При оценке по переделок, часто упускаются из вида возможные проблемы и риски, оценка оказывается инертной и неточной. Отсюда недовольство всех: от менеджера проектов, до тех, кто, возможно, будет доделывать переделки после вас.

Перманентный дедлайн

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

Все дело в стрессе?

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

От обиды неизбежно возникает стресс, ведь вы совсем недавно нормально общались с коллегой, а теперь лежите в окопах по разные стороны баррикад и ждете, кто же первый кинет гранату.

А что делать-то?

А делать что-то нужно, иначе конфликты на почве ошибок и пропуска сроков начнут разъедать команду изнутри. Если вы лидер проекта, минимизируйте конфликты в коллективе, пусть принимая удар на себя. Или переводите конфликты более компетентному менеджеру проекта, что, конечно, займет больше времени.
Стив Макконнелл рекомендует проводить ежедневные ревизии кода, на которых, не переходя на личности вроде: «Кто это написал? Петров? Петров, вы говнокодер плохо написали!», обсуждать проблемные участки кода. Но это лишь решение одной проблемы.
Решение другой проблемы лежит в вас. Если вы постоянно перерабатываете, если устаете и не расслабляетесь, если вам не нравится с кем-то работать, даже если вас не устраивает зарплата, вы становитесь недовольным программистом. А недовольный программист == неэффективный программист.
Не стесняйтесь выражать ваше мнение, но держите себя в рамках приличия.
Не забивайтесь в угол, ведь вам еще работать и работать.
Отдыхайте побольше, это очень важно для постоянно думающих людей.
И да, хороший код доставляет огромное удовольствие от его написания.
Просто подумайте об этом.