They write the right stuff

Niedawno znalazłem w sieci tytułowy artykuł: They Write the Right Stuff. W dużym skrócie opowiada o rozwoju szeroko rozumianego oprogramowania wykorzystywanego w misjach promów kosmicznych.

Przydługi wstęp opisujący automatyczny proces wznoszenia statku kosmicznego, następnie mające wywoływać wrażenie statystyki dotyczące odpowiedzialnego za to oprogramowania oraz krótki opis tła.

Właściwy początek artykułu również nieco nudny – przedstawienie kilku osób zaangażowanych w kod, którzy zapewniają o perfekcjonizmie kodu, za który są odpowiedzialni. Dla kontrastu następuje porównanie z wszechobecnym oprogramowaniem, z którym stykamy się w niemal każdej dziedzinie życia oraz stwierdzenie, że wszystko to jest tworzone szybko i niechlujnie. Nic nowego, do tego momentu prawie zrezygnowałem z dalszego czytania. Ale to właśnie odtąd zaczyna się sedno artykułu – proces tworzenia oprogramowania dla NASA.

Sprawa jest opisana bardzo dokładnie: od szczebla finansowego, po zarządzanie, projektowanie, zapewnianie jakości oraz samo programowanie.

Najwyższa warstwa to opis żywcem wyjęty z dowolnego, dużego korpo – przeładowane informacjami prezentacje dla przedstawicieli sponsorów projektu, narzekanie na ilość czasu, składanie pisemnych zapewnień. Z tego wszystkiego wyróżniają się zdecydowanie spotkania menedżerów odpowiedzialnych za oprogramowanie z uczestnikami misji, którą ono obsługuje – tak, aby poznać osobiście ludzi, którzy mogą zginąć, jeżeli soft będzie posiadał błędy. O tym, jak dużą presję musi to wywoływać najlepiej mówi fakt, że wszyscy menedżerowie wymienieni w artykule zmienili branże.

Projektowanie opisuje klasyczny model waterfall. Wszystko musi być przedyskutowane, ustalone i opisane w najdrobniejszych szczegółach. Osoby wypowiadają się z dumą o tym, że każda najmniejsza zmiana wymaga ponownego uruchomienia machiny projektowej. Trochę mnie to zdziwiło, podobnie jak chwalenie się używaniem bugtrackera.

Zapewnienie jakości odbywa się w dziale weryfikacji, odseparowanym w strukturze firmy od działu programistycznego. Wspomniana jest też praktyka weryfikacji już w trakcie pisania kodu, przez dodatkową osobę. Każdy znaleziony błąd jest zapisywany w bugtrackerze wraz z wszystkimi podstawowymi informacjami.

Dział programistyczny składa się z normalnych, “nudnych” ludzi: dorosłych programistów z rodzinami, dziećmi, posiadających zrównoważony stosunek pracy do życia prywatnego. Nie ma nadgodzin i niespodziewanego pośpiechu, zaś indywidualiści są stąd natychmiast eliminowani.

Z każdego znalezionego błędu wyciągane są wnioski, czasem aż do przesady. Wnioski nie oznaczają w tym przypadku osobistych konsekwencji – w przeciwieństwie do typowych korporacji, tutaj nie szuka się dupochronów i winnych. Winny jest zawsze proces i to proces, który dopuścił do powstania błędu musi zostać zmieniony tak, aby sam z siebie mógł tego typu sytuacje wykluczać. Brzmi strasznie skrupulatnie, ale jest to zrozumiałe – błędy w przypadku misji kosmicznych mogą kosztować ludzkie życie i miliardy dolarów, więc obarczanie winą pojedynczych osób przy takiej skali nie ma sensu.

Opisany proces wygląda naprawdę dobrze, chociaż oprogramowanie dla NASA to jednak skrajny przypadek rynku software’owego. Pieniądze nie są tu problemem, deadline’y nie są narzucane, lecz ustalane praktycznie przez samych developerów, oraz tylko jeden projekt naraz. Problemy te same, lecz warunki w porównaniu z resztą rynku (krytykowanego na początku) nieco utopijne.

Co jest najciekawsze w artykule? To, o czym dowiedziałem się mniej więcej w połowie jego czytania, gdy z ciekawości spojrzałem na datę opracowania. Miało to miejsce w 1996, 20 lat temu. Na kilka lat przed rozpoczęciem się mojej własnej przygody z komputerami i na kilkanaście przed tym, gdy zacząłem zawodowo zajmować się programowaniem i zderzać z identycznymi problemami. Niewiele się zmieniło, prawda?

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Time limit is exhausted. Please reload CAPTCHA.