Szukasz kursu specjalistycznego z BHP, SEP lub kursu excel? Kurs edukacyjny!

Ból programowania – dalszy opis

Po trzecie, projektowanie wielkich zadań sprawia przyjemność. Wyszukiwanie podstępnych, drobnych błędów to tylko żmudna praca. Każda działalność twórcza wymaga długich godzin drobiazgowej, męczącej pracy, a programowanie nie jest tu wyjątkiem.

Po czwarte, poprawianie programu ma liniową, albo i jeszcze gorszą, zbieżność, podczas gdy pod koniec tego procesu należałoby się raczej spodziewać zbieżności kwadratowej. Testowanie przeciąga się w nieskończoność, a znalezienie ostatnich, trudnych błędów wymaga więcej czasu niż znalezienie tych pierwszych.

Wreszcie tym, co przepełnia czarę goryczy, jest świadomość, że produkt, nad którym się pracowało tak długo, w chwili ukończenia (albo i wcześniej) okazuje się przestarzały. Koledzy i konkurenci są już na tropie nowszych, lepszych rozwiązań. Dochodzi do tego, że nie tylko myśli się o zastąpieniu własnego dziecka innym, nowym, ale już się to planuje.

Zawsze wygląda to gorzej, niż jest w istocie. Nowy, lepszy produkt nie jest na ogół dostępny w chwili, kiedy kończymy własny. O nim się tylko mówi. Do opracowania go też przecież potrzeba wielu miesięcy. Prawdziwy tygrys nigdy nie dorówna papierowemu, chyba że ma się sprawdzić w działaniu.

Oczywiście baza techniczna, tak ważna przy tworzeniu, ciągle się rozwija. Z chwilą zamrożenia projekt staje się przestarzały w kategoriach zastosowanych w nim rozwiązań. Wdrożenie rzeczywistego produktu wymaga jednak ustalenia faz pracy i wyznaczenia zadań ilościowych. Przestarzałość wdrożonego produktu należy oceniać jedynie pod kątem innych wdrożonych produktów, a nie pod kątem nie zrealizowanych koncepcji. Wyzwaniem dla programisty i jego misją jest znalezienie rzeczywistych rozwiązań konkretnych problemów zgodnie z przyjętymi terminami i przy dostępnych zasobach.

Programowanie jest zatem tym właśnie – smolistym grzęzawiskiem, w którym utknęło wiele prac, i twórczą działalnością, która daje radość, ale sprawia ból. Według wielu ludzi, radość przeważa nad bólem. To dla nich właśnie usiłuję w pozostałej części książki przerzucić kładkę nad grzęzawiskiem.

Więcej przedsięwzięć programistycznych zakończyło się niepowodzeniem z powodu braku czasu kalendarzowego niż ze wszystkich innych powodów razem wziętych. Dlaczego to zjawisko jest tak powszechne?

Po pierwsze, nie mamy dobrych metod szacowania czasu. Co ważniejsze, milcząco zakładamy, że wszystko pójdzie dobrze. Po drugie, w naszych metodach szacowania czasu mylimy nakłady pracy z postępem prac. Zakładamy skrycie, że liczba ludzi i liczba miesięcy to wielkości zamienne. Po trzecie, ze względu na niepewność co do szacunków szefom zespołów oprogramowania brakuje często owej uprzejmej stanowczości, cechującej szefa restauracji „Antoine”.

Po czwarte, niedostatecznie kontrolujemy harmonogram prac. Metody sprawdzone i rutynowo stosowane w innych dyscyplinach technicznych uważa się w inżynierii oprogramowania za radykalne innowacje.

Po piąte, gdy zauważymy poślizg w realizacji prac, naturalną (i tradycyjną) naszą reakcją jest zwiększenie liczby zatrudnionych. Zupełnie jak gaszenie pożaru benzyną. To tylko pogarsza sytuację, i to poważnie. Większy pożar wymaga większej ilości benzyny – i tak w kółko, aż dochodzi do katastrofy. Kontrolowanie harmonogramu prac jest przedmiotem odrębnego eseju. Teraz zajmijmy się dokładniej innymi aspektami naszego problemu.

Podobne Artykuły

Zostaw odpowiedź

Twoj adres e-mail nie bedzie opublikowany.