Цитаты из книги The Mythical Man-Month: Essays on Software Engineering

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

В течении ряда лет при планировании разработки программного обеспечения я пользуюсь следующим эмпирическим правилом: 1/3 - планирование 1/6 - написание программ 1/4 - тестирование компонентов и предварительное системное тестирование 1/4 - системное тестирование при наличии всех компонентов

В конце концов, я программист по образованию, а оптимизм - это профессиональная болезнь нашего ремесла.

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

Каким образом проект может сместиться на год?

...По одному дню за раз.

Планируйте выбросить первую версию: вы все равно это сделаете.

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

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

Одна из причин заключается в том, что только небольшая часть, возможно, 20% времени сотрудника исполнительного звена тратится на части работы, которые требуют информации, отсутствующей в его памяти. Остальное - это обмен информацией: выслушивание, отчеты, обучение, увещевание, консультирование, поощрение.

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

Глава 16. Серебряной пули нет.

Программные проекты чаще проваливаются из-за нехватки календарного времени, чем по всем остальным причинам, вместе взятым

Крайне упрощая, сформулируем Закон Брукса:
Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.

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

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

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

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