Тест Джоэла. Часть Четвёртая.

6. Есть ли у вас актуальный план работ?
Что заставляет нас составлять расписания? Если ваш код очень важен для бизнеса, то найдется много причин, почему бизнесу так важно знать, когда код будет сделан. Все знают, что программистов раздражает составление расписаний. "Когда будет сделан, тогда и будет сделан!" - кричат они на бизнесменов.
К сожалению, только этим дело не исчерпывается. Бизнесменам надо задолго до поступления кода в продажу принять слишком много решений, относящихся к планированию демонстрационных версий, коммерческих показов, рекламы и т.д. И единственный способ сделать это - иметь расписание и вовремя его обновлять.
Другая важная причина иметь расписание состоит в том, что оно заставляет вас решать, какие возможности надо делать, а какие (наименее важные) найти и отбросить, вместо того чтобы обрастать мелочью (так называемый "эффект снежного кома").
7. имеется ли у вас спецификация?
Написание спецификаций похоже на чистку зубов вощеной ниткой: все согласны, что это полезно, но никто такого не делает.
Не знаю, почему это так, но, скорее всего, потому, что большинство программистов ненавидят писать документы. В результате, когда команды состоят исключительно из программистов, атакующих проблему, то эти программисты предпочитают выразить свое решение в коде, а не в документах. Они скорее углубятся в написание кода, чем вначале создадут спецификацию.
Обнаружив неполадки на этапе проектирования, вы можете легко их исправить, отредактировав несколько строк текста. Если код уже написан, то стоимость исправления неполадок намного выше, как эмоционально (людям очень не нравится выбрасывать код), так и с точки зрения времени, отсюда и сопротивление настоящему исправлению проблем. Программное обеспечение, скомпонованное без спецификации, обычно оказывается плохо спроектированным, и расписание его исправления выходит из-под контроля. Эта проблема, возможно, была у Netscape, чьи первые четыре версии каждый раз по мере готовности превращались в такое месиво, что руководство приняло глупое решение выбросить весь имеющийся код и начинать все заново. А потом это руководство сделало такую же ошибку с проектом Mozilla, создав чудовище, вышедшее из-под контроля, и только спустя несколько лет этот проект добрался до стадии альфа-версии.
Моя излюбленная теория легко решит эту проблему, приучая программистов охотнее заниматься писательством (для этого их нужно отправить на интенсивные курсы). Другое решение состоит в том, чтобы нанимать способных менеджеров по разработке и сопровождению программ, которые будут писать спецификации. В обоих случаях надо обеспечивать соблюдение простого правила: "Никакого кода без спецификации".