Собор и Базар

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

Не колебайтесь выбрасывать устаревшие особенности, если вы можете сделать это без потери эффективности

Совершенство в разработке достигается не тогда, когда нечего добавить, а тогда когда нечего убрать.

Венбегр в Psychology Of Computer Programming (New York, Van Nostrand Reingold 1971) представил неудачно названное понятие «неэгоистичного программирования». Хотя он не смог осознать бесполезность «принципа команды», он, вероятно, был первым, кто рассмотрел эту проблему всвязи с программным обеспечением. Ричард П, Габриэл, рассматривая Unix до эры Linux, спорит о превосходстве примитивной модели базара в своей статье: Lisp:Good News, Bad News, and How to Win Big.

Де Марко и Листер Peopleware:Productive Projects and Teams (New York;Dorset House, 1987; ISBN 0-932633-05-6) – это бесценный джем, где я с удовольствием увидел цитаты из Фреда Брукса. Хотя только небольшая часть из высказываний авторов напрямую применима к Linux, рассматриваемые условия, необходимые для творческой работы, помогут тем, кто попытается перенести некоторые принципы модели базара в более коммерческий контекст.

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

Потому брать за основу английйский язык невыгодно, так как в нем около 50% избыточных конструкций.

1 – Я часто выпускал релизы(не реже чем каждые 10 дней, а во время периодов интенсивной разработки каждый день.)

2 – Я увеличил список бета тестеров, добавив к нему каждого, кто контактировал со мной на тему fetchmail'a.

3 – Каждый раз когда я делал релиз, я рассылал обЪявления бета-тестерам, приглашая людей активно сотрудничать.

4 – Я слушал своих бета-тестеров и поддерживал с ними обратную связь.

Или менее формально: «При достаточном количестве глаз, ошибки выплывают на поверхность.» Я назову это – законом Линуса.

3. «Даже если вы не планировали выбрасывать первую версию; выбрасывая ее, вы все равно выигрываете.» (Фред Брукс «The Mythical Man-Month», глава 11) Другими словами, когда вы первый раз реализуете какоелибо решение, вы часто не понимаете проблему до конца. Во второй раз вы уже набираете достаточно знаний, чтобы сделать это правильно. Итак, если вы хотите написать что-нибудь стоящее, лучше хотя бы один раз начать все заново.

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

Хорошие структуры данных и плохой код работают несколько лучше, чем хороший код и плохие данные.