Міфічний людино-місяць

Час виконання проєкту не обернено пропорційний числу програмістів, принаймні з двох причин.

1. У програмуванні, на відміну від, наприклад, збирання бавовни, робота не може бути довільно розділена на кілька незалежних частин. Частини проєкту залежать одна від одної, і деякі завдання можна починати виконувати лише після того, як будуть закінчені інші.
2. Програмісти повинні витрачати частину часу на взаємодію один з одним.

Якщо є N програмістів, то кількість пар програмістів N(N-1)/2, тобто зі зростанням числа програмістів витрати часу на взаємодію ростуть квадратично. Тому починаючи з якогось N, зростання числа програмістів уповільнює виконання проєкту.

Якщо терміни закінчення проєкту зірвані, наймання нових програмістів уповільнює виконання проєкту і з іншої причини: новачкам потрібен час на навчання. У книзі сформульовано Закон Брукса:

Якщо проєкт не вкладається в терміни, то додавання робочої сили затримає його ще більше.

Якщо програмістів занадто багато, проєкт може бути взагалі ніколи не закінчений: через загальну плутанину, спроби виправити вади породжують нові, так що система не поліпшується.

Програмний продукт відрізняється від програми:

• максимально узагальненим діапазоном та видом вхідних даних;
• ретельним тестуванням, що є несподівано складним етапом;
• наявністю докладної документації.

Програмний продукт вимагає втричі більше витрат часу, ніж програма.

Програміст, який розробляє свою другу систему, схильний додавати всі ті можливості, які він не зміг додати в свою першу систему (через брак часу). Тому друга система часто виявляється перевантаженою можливостями.

Для забезпечення концептуальної цілісності системи необхідно відокремити архітектуру від реалізації. Один головний архітектор (або невелика група), вирішують, що повинно входити в систему, а що не повинно. «Дуже крута» ідея може бути знехтувана, якщо пропоновану можливість важко вписати в загальний дизайн системи. Простота дуже важлива; може бути корисним реалізувати лише частину можливостей, на які здатна система, оскільки якщо система занадто складна, частина її можливостей будуть залишатися невикористаними.

Головний архітектор повинен сформулювати свої рішення у вигляді керівництва для користувача.

Кожний менеджер проєкту повинен скласти невеликий набір формальних документів, що описують цілі проєкту, як, хто і коли буде їх реалізовувати, і скільки вони будуть коштувати. Ці документи можуть розкрити невідповідності, які інакше було б важко помітити.

Кожна група розробників отримує набір вимог до своєї частини системи, включаючи точний опис її функціональності та граничні вимоги до процесорного часу, пам'яті, місця на диску і т.д.

Щоб запобігти катастрофі, групи розробників повинні взаємодіяти одна з одною всіма можливими способами. Замість того щоб робити припущення з приводу функції, що він її реалізовує, розробник повинен ставити архітекторові запитання, оскільки припущення можуть виявитися геть невірними.

Перед тим як розробляти остаточну систему, необхідно розробити пілотну систему. Пілотна система виявить помилки в проєктуванні, після чого вона повинна бути повністю перероблена.

Розумно, якщо в групі розробників є один "гарний" програміст, який реалізовує найкритичніші частини системи, і кілька інших, що допомагають йому або реалізовують менш критичні частини. До речі так проводять хірургічні операції. Крім того, на думку Брукса, найкращі програмісти працюють в 5-10 раз швидше за інших.

Замість того, щоб кожний програміст писав власні утиліти, в кожній групі розробників повинен бути один програміст, відповідальний за написання утиліт для своєї групи (наприклад, генератор коду, що створює код згідно з якимись специфікаціями). Повинна бути також група, яка створює утиліти для всіх програмістів, що працюють над системою.

Під час створення системи, вимоги користувача до неї можуть змінюватись під впливом його досвіду роботи з незакінченою системою. Ці побажання користувача слід враховувати, але лише до певного моменту, інакше робота над системою ніколи не буде закінчена. Після цього специфікації заморожуються, і всі такі вимоги змін відкладаються до початку роботи над наступною версією.

Брукс пропонує 2 способи знизити вартість розробки програмного забезпечення:

• Найняти програмістів лише після того, як побудована архітектура системи. Інакше якщо ця стадія буде тривалою, наприклад розтягнеться в кілька місяців, програмістам буде нічого робити.
• Придбати частину програмного забезпечення у інших розробників.