Една от класиките сред книгите за управление на софтуерни проекти. Написана преди повече от 40год., много от тезите са валидни и днес, което е и причината за преиздаването ѝ след толкова време.
Описват се основни възприятия в процеса на разработка, върху които малко хора са се замисляли и осмисляли – като защо обичаме да програмираме, какви са негативните страни от това, защо не успяваме да прогнозираме добре необходимото време за разработка. Някои от причините за последното са това, че сме оптимисти, не включваме в преценката си времето за комуникация, за дебъгване и тестове. Съществува също така грешното схващане, че работата на един разработчик е константа като човекочас. Съответно при забавяне в разработката на проект най-лесното решение е да се добавят още хора. Пропуска се обаче, че това внася допълнително натоварване към останалите и изисква повече време докато екипът се сработи. От тук произлиза и изводът, станал известен като закон на Brooks – “Adding manpower to a late software project makes it later”.
Друга интересна концепция, която се развива в книгата е начин за управление на разработката на голям софтуерен проект от голям екип разработчици (100+). Представят се предизвикателствата пред ефективното управление на много хора и един подход, който може да помогне – създаването на малки “хирургични екипи”. Малките екипи се състоят от един основен разработчик – “хирургът”, който взима решенията и разработва най-важните части от софтуера. Около него се създава екип от поддържащи роли – “копилот”, който може да върши всичко, но е с по-малък опит; “администратор”, който се занимава с административните дейности; “редактор” – документацията; двама “секретари” помагащи на администратора и редактора; “чиновник”, “инструменталист”, “тестер”, “адвокат на езика”, който познава тънкостите на използвания език за програмиране. По този начин комуникацията се разделя по определени роли и се улеснява скалирането на екипите.
Концептуалната цялост е много важен аспект при разработката на софтуер. За това е нужна добре разработена, а също така и добре поддържана спецификация на проекта. Въпросът тук е дали това да се прави единствено от екип от архитекти или и от самите разработчици, които ще имплементират заданието. Авторът развива тезата, че използването на отделен екип за спецификацията няма да доведе до забавяне на проекта.
В книгата също се обръща внимание на тънкостите при водене на комуникация, документирането на проекта. Дават се съвети за използването на правилните инструменти за целта. Както и създаването на софтуер с нагласата, че той ще бъде постоянно променян и последствията от това. Търсят се подходи, които да гарантират успешното разработване на софтуер и може би най-важният извод от това – няма такива, за което са посочени множество аргументи, изследвания. Дискутират се и други гледни точки. Накрая завършва с проверка на валидността в днешно време на изводите направени преди 40год.
Като цяло много полезна книга, в която се обръща внимание на причините за проблемите при разработката на софтуер, дават се съвети за разрешаването им и правилното управление.