Okładka Legendarny Osobomiesiąc
  • Tytuł: Legendarny Osobomiesiąc
  • Autor: Frederick P. Brooks Jr.
  • Rok: 2019 (1995 EN)
  • ISBN: 978-83-283-5090-8

Zgodnie z obietnicą krótka recenzja jednej z najciekawszych książek o zarządzaniu projektami IT, jaka kiedykolwiek powstała.

Szczypta historii

Autorem książki jest Frederick BrooksW, który był menadżerem projektu OS/360W z przyległościami. Zatem mamy tu do czynienia z człowiekiem, który walczył w okopach IT w czasach, gdy duża część z nas nie za bardzo miała jeszcze możliwość zaistnieć w jakiejkolwiek formie biologicznej. Pierwsze wydanie książki było w 1975, a drugie w 1995. I właśnie z tym wydaniem „na dwudziestolecie” mamy do czynienia. Polskie tłumaczenie ukazało się w 2019 roku.
Książka jest stara i ma to przeróżne konsekwencje. Siadając do lektury, należy o tym pamiętać.

Konsekwencja pierwsza – język

Legendarny Osobomiesiąc jest napisany w specyficzny sposób. Stare książki już tak mają, że język, którym posługują się autorzy, jest trudniejszy w odbiorze. Jeżeli dodamy do tego swoistą manierę używania słów dłuższych niż konieczne oraz czasami osobliwą składnię, to efekt końcowy jest „skomplikowany”.
Tak też jest tutaj. Książka jest napisana w bardzo „barokowym stylu”, który odszedł do lamusa wraz z nastaniem blogów i popularyzacją krótszych form cyfrowych.

Dodatkowo wiele z poruszanych w niej problemów nie istnieje już w zbiorowej świadomości IT. Tym samym niektóre elementy zdają się dziwne i bezsensowne.
Język książki determinuje też sposób jej tłumaczenia. Niewdzięczna to praca, bo z jednej strony należy zachować oryginalny charakter, a z drugiej aż prosi się o uwspółcześnienie. Jednakże tłumacz ciała nie dał i jego pracę oceniam na całkiem, całkiem.

Konsekwencja druga – kontekst

Jeżeli damy tę książkę osobie, która nie ma pojęcia, jak wygląda współczesny cykl rozwoju oprogramowania, to bardzo szybko okaże się, że mamy poważny problem. Pojawią się pytania w tylu „ile czasu zajmuje ci debuggowanie”, „czy mam gotową osobną stację roboczą do debuggowania”, „ile linii kodu dostarczamy w ciągu roku”. Ciekawe, prawda? Brooks pisał książkę, gdy Intel pokazał światu procesor 8080W, czyli gdy wybuchła rewolucja mikrokomputerów. Drugie wydanie pojawiło się w roku premiery Windowsa’95. Zatem autor ma bardzo ograniczony zasób wiedzy w porównaniu do nas. Dzisiaj.
Oczywiście można podjąć próbę translacji pewnych aspektów inżynierii oprogramowania z dawnych czasów na nam współczesne. Jest to jednak trud nie tyle daremny ile bezsensowny.
Drugie wydanie zostało co prawda uzupełnione o 20 lat doświadczeń, a co za tym idzie m.in. dyskusję nad klasycznym już dzisiaj artykułem Brooksa pt. „There is no silver bullet”. Jednak nadal istnieje 25-letnia wyrwa w wiedzy pomiędzy współczesnością, a czasami drugiego wydania.

Konsekwencja trzecia – wnioski autora

To samo dotyczy wniosków, które przedstawia autor. Z dzisiejszej perspektywy wiemy, że wiele z zaproponowanych rozwiązań nie sprawdziło się, albo spowodowało poważne problemy. Mam tutaj na myśli przede wszystkim wprowadzenie „wszechwiedzącego” i niekodującego architekta, próby formalizacji na poziomie globalnym (dla danej organizacji), czy też założenie, że zespoły programistów nie są w stanie sprawnie się komunikować.
Oczywiście Brooks miał rację w kilku kwestiach. Programowanie wizualne nie zawojowało rynku. Podobnie jak automatyczne tworzenie kodu na podstawie specyfikacji.
Nadal kluczową rolę w procesie tworzenia oprogramowania odgrywa przygotowanie specyfikacji. Nadal mamy problemy z sensownym testowaniem naszych programów, choć proces debuggowania zastąpiliśmy metodykami w rodzaju TDD. Nadal też nie mamy idealnej metody komunikacji ani niczego co pozwoliłoby na precyzyjne planowanie czasu pracy nad zadaniami.
W końcu w książce tej mamy sformułowane Prawo Brooksa W wraz z późniejszą jego dyskusją i weryfikacją empiryczną, która jest wspomniana w drugim wydaniu. Jest to też największa wartość tej książki, która nie ulegnie dezaktualizacji.

Dla kogo ta książka?

Na pewno nie dla młodych menadżerów. Z racji wieku nie będzie to książka, która cokolwiek im da. Jednocześnie każdy doświadczony menadżer powinien ją przeczytać. Pozwoli mu to zrozumieć, w jaki sposób jego decyzje mogą wpływać na zespół. Jaka jest ich rola w zespole. Dlaczego pojawiają się problemy?
Czy jednak jest to książka dla programistów?

Książka historyczna

Chcąc zrozumieć współczesność, należy przeanalizować przyczyny. Te mają swoje źródła w historii. Książka Brooksa jest pod tym względem idealna. Jako że jej autor uczestniczył w jednym z najbardziej skomplikowanych projektów w historii informatyki, a następnie spisał swoje przemyślenia, to wnioski z tamtych wydarzeń stały się podstawą do analizy i opracowania metodyk wytwarzania oprogramowania. Metodyki te stały się standardem na kolejnych 30 lat. W dodatku wrosły one w branżę i nadal są ważnym jej elementem. Szczególnie że pokolenie starszych menadżerów uczyło się tworzenia oprogramowania m.in. na tej książce.
Dlatego jest to lektura obowiązkowa dla wszystkich programistów, którzy nie chcą ślepo przeć do przodu, nie zważając na otoczenie. W rozdziałach dodanych w drugim wydaniu Brooks z entuzjazmem odnosi się do programowania obiektowego. Entuzjazm ten podobny jest do tego, jaki towarzyszy obecnie programowaniu funkcyjnemu. Czy za 25 lat nie będziemy mieli podobnego „moralniaka”, mówiąc o FP?

Warto.