Фредерик Брукс R.I.P.

Брукс был голова. Это он обнаружил, что при росте команды программистов как N, объём производимого кода тоже растёт как N, но количество ошибок в коде увеличивается как N квадрат.

Ещё из Брукса:

1. Successful software always gets changed.
2. All programmers are optimists.
3. Good judgement comes from experience, and experience comes from bad judgement.
4. Software work is the most complex that humanity has ever undertaken.
5. I am more convinced than ever. Conceptual integrity is central to product quality.
6. Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.
7. Improving your process won't move you from good to great design. It'll move you from bad to average.
8. The hardest single part of building a software system is deciding precisely what to build. Therefore the most important function that software builders do for their clients is the iterative extraction and refinement of the product requirements. For the truth is, the clients do not know what they want. They usually do not know what questions must be answered, and they have almost never thought of the problem in the detail that must be specified.
9. How does a project get to be a year behind schedule? One day at a time.
10. You can learn more from failure than success. In failure you're forced to find out what part did not work. But in success you can believe everything you did was great, when in fact some parts may not have worked at all. Failure forces you to face reality.
11. The bearing of a child takes nine months, no matter how many women are assigned.
12. Brooks’ Law: Adding manpower to a late software project makes it later.

(отсюда)

Хоторнский эффект

Решили однажды менеджеры изучить, как влияет освещённость на результаты труда. Реальная история: фабрика Hawthorne Works компании Western Electric, Чикаго 1927-1932. Несколько лет исследовали мотивацию и производительность, заметьте. Пришли к выводам:

• Увеличиваем освещённость - производительность растёт.
• Уменьшаем освещённость - производительность растёт.
• Оставляем освещённость той же - производительность растёт.

С тех пор эта аномалия называется "хоторнский эффект". На разработку софта ровно так же распространяется.

Это я листаю книжку "Software Engineering Economics" - рекомендую. Она лохматого 1981 года, но с тех пор никто ничего более толкового не придумал про метрику софта. До этого была книжка Фреда Брукса, но она вообще из 60-х, те методы давно умерли.