Проекты. Программирование vs Производство

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

Автор начинает так:

"Хороший программист, работающий над собственным проектом, может удерживать его целиком в голове так, как удерживает математик уравнение, которое решает. Математики не решают задачи на листке бумаги, так, как этому учат детей в школе. Вместо этого большинство операций они производят в уме, создавая некий образ в голове, примерно как мы можем мысленно представить образ дома, в котором провели детство. С программированием все точно так же. Вы можете создать некий образ всего текущего проекта в голове и рассмотреть его тщательно со всех сторон."

Как персонаж, имеющий диплом физика-ядерщика, и посему немножко знакомый с матаппаратом, возражу, не вставая с места: ежели мы говорим о серьезных уравнениях, то это не так: математики _именно_ решают на листке бумаги, ибо мало-мальски серьезное уравнение удержать в голове невозможно. И, кстати, невозможно потом определить, где ты "проехал Лопухинку" ;).

Как видим, Пол распространяет данный подход и на программистов, и сразу дает рекомендации по _управлению_ разработкой:

1. Как можно меньше отвлекайтесь.
2. Работайте запоем.
3. Пишите на лаконичных языках.
4. Постоянно переписывайте программы.
5. Пишите код, который удобно читать вам.
6. Работайте маленькими группами.
7. Не допускайте редактирование одного и того же кода несколькими людьми.
8. Начинайте с малого.

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

1. Как можно меньше отвлекайтесь.
Ну... Постоянно отвлекаться вообще вредно. Но в проекте, длящемся более однго дня всем участникам _приходится_ отвлекаться. Хотя бы на сон и отдых. А в реальных проектах, даже сравнительно небольших, от месяца, постоянная концентрация чревата для программиста нервным расстроийством.

2. Работайте запоем.
Из той же оперы. Месяц таких запоев (знаменитая "сотка в неделю" -- 100 hours/week), и любой человек, даже с устойчивой психикой, -- кандидат на "социальную адаптацию".

3. Пишите на лаконичных языках.
Нет. Извольте писать на тех языках, и в рамках тех технологий, которые наиболее подходят к решению конкретной задачи. В процессе подготовки проекта аналитик(и) (при содействии представителей заказчика и/или сотрудников маркетинга) определяет набор инструментов, исходя из массы условий: оптимизации времени и стоимости разработки, learning curve, стоимости владения, затрат на оборудование, совместимости с legacy-платформами и еще много-много с чем. Блеск технологических знаний разработчика несколько блекнет на фоне необходимости убедить заказчика накупить оборудования и стороннего софта на $100K+ или использовать технологию, о которой слышали 4-ре человека, двое из которых работают в вашей команде и двое -- занимаются теорией в Беркли!

4. Постоянно переписывайте программы.
Без комментариев. Это уже за гранью добра и зла... И _любого_ времени. И _любого_ бюджета.

5. Пишите код, который удобно читать вам.
Нет. Пишите код в рамках стандарта. Ваши коллеги не обязаны ломать глаза об ваши опусы. А им придется, ибо человек имеет привычку болеть, ходить в отпуск, менять место работы, да и просто может быть назначен на другую задачу. С этим согласится _любой_ программист, которому довелось хотя бы раз вносить изменения в чужой код. А других _профессиональных_ программистов не бывает: ежели еще не довелось, то доведется завтра.

6. Работайте маленькими группами.
Нет. Размер команды определяется масштабом задачи. А не выдумками.

7. Не допускайте редактирование одного и того же кода несколькими людьми.
Вопрос грамотного распределения задач. Разумеется, в идеале не стоит плодить "десять нянек", но жизнь далека от идеала. И, конечно же, использование системы контроля версий -- жизненная необходимость.

8. Начинайте с малого.
Имеется ввиду: "Если вы начнете со слишком сложной и объемной задачи, вы, вероятно, никогда не сможете охватить ее целиком. Если перед вами стоит подобная задача, начните не с ее формального описания, а с написания прототипа, который решает одну из ее подзадач."

Да! Да! А еще: любая телега едет лучше, ежели лошадь запрячь сзади! Вы не знали? Ну что ж, тогда последуйте данному совету. Шанс получть продукт, не делающий толком ни хрена, зато "красиво помаргивающий", будет очень велик.

И в заключении:

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

...

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

Вот как? А я почему-то не удивлен :)... Скажу более: вероятно, шанс успешно завершиться и, в конечном итоге, принести прибыль имеют только проекты, игнорирующие данные правила, и следуюшие стандартам. А Вы не согласны?