Wydania Oprogramowania: Kiedy Wystarczająco Dobrze, Jest Wystarczająco Dobrze

by Rosario Disomma
Wydania Oprogramowania: Kiedy Wystarczająco Dobrze, Jest Wystarczająco Dobrze thumbnail

W lipcu, EuroPython 2013 odbył się we Florencji, we Włoszech, po raz trzeci z rzędu. Kilka słów o mnie: jestem Włochem i programistą Pythona, dlatego z radością dzielę się więcej na temat moich doświadczeń na EuroPythonie. Python ma niesamowitą społeczność, pełną niektórych z najmądrzejszych i najbardziej inspirujących osób w branży IT. Po byciu częścią tej społeczności przez siedem lat, mogę szczerze powiedzieć, że konferencje Pythona to przede wszystkim ludzie. To ludzie czynią tę społeczność wielką.

Jedną z tych inspirujących osób jest Alex Martelli, starszy inżynier w Google i członek Python Software Foundation. W tym roku przedstawił przemówienie inauguracyjne na EuroPython pod tytułem “Dobre Wystarczy” to Dobre Wystarczy! lub, jak powiedział, cytując Richarda Gabriela: podejście New Jersey, znane też jako “Gorsze jest lepsze” w przeciwieństwie do “podejścia MIT/Stanford, znanego jako “To Coś Slusznego.” Nie byłem pewien, o czym będzie mówił, ale tytuł był intrygujący. I jedno czego nauczyłem się z przemówień Martellego przez ostatnie siedem lat, to że kiedy on mówi, najlepiej jest słuchać, uczyć się i robić notatki. Więc, to właśnie zrobiłem.

Prezentacja poruszyła dwa różne podejścia do wydawania oprogramowania. Pierwsze z nich, “The Right Thing”, zaleca dążenie do perfekcji (zadowolenie się wydaniem oprogramowania, które jest poniżej „idealnego”, jest godnym pożałowania kompromisem). Drugie, “Worse is Better”, mówi o zachowaniu prostoty, wystarczającej dobrej jakości, szybkiej premierze, częstych aktualizacjach, zdobywaniu dużej ilości opinii (to jest „podejście z New Jersey”, ponieważ Unix jest dobrym przykładem i został napisany w New Jersey).

Martelli wyjaśnił, jak Richard Gabriel zidentyfikował cztery podstawowe wartości, które oba te podejścia mają wspólne: prostota, poprawność, spójność i kompletność. Następnie wyjaśnił, że to, co naprawdę się liczy, to priorytet przyznawany tym wartościom. Wnioski Gabriela można streścić dwoma cytatami:

Filozofia właściwego działania opiera się na pozwalaniu ekspertom robić to, w czym są eksperci

doprowadź rzecz do końca, zanim użytkownicy zaczną z niej korzystać. 

Gorsze jest lepsze wykorzystuje naturalne zalety inkrementacji

rozwój. Stopniowa poprawa zaspokaja pewne ludzkie potrzeby…

Poszedł jeszcze dalej, wskazując na to, jak interpretacja Gabriela jest bliska temu, co Eric Raymond opisał w swojej książce, „Katedra i Bazar”, w której opisuje dwa rozbieżne modele rozwoju oprogramowania: katedrę, gdzie władzę mają eksperci i wszystko koncentruje się na działaniach ekspertów, w przeciwieństwie do Bazaru, który jest zorganizowany chaotycznie i opiera się na pracy mas, gdzie władzę mają osoby bezpośrednio zaangażowane, ale nieuchronnie obecni są również ci, którzy tylko pomagają, ponieważ potrzebują produktu bazarowego do niepowiązanych zadań.

Oczywiście, Raymond skupiał się na błędach i wierzył, że milion oczu przyspieszy proces odkrywania błędów – i to właśnie jest sedno sprawy. Aby milion osób na to patrzyło, musisz udostępnić kod. Musisz wypuścić go w świat rzeczywisty i pozwolić ludziom z niego korzystać. Jak powiedział Martelli, jeśli chcesz wydawać tylko „Perfekcję”, jeśli chcesz, aby ekspert robił to, co ekspert, wówczas potrzebujesz „Wielkiego Projektowania na Początek”, doskonałej identyfikacji wymagań, doskonałej architektury, doskonałego projektu, doskonałych implementacji itd. I to zajmie wieczność! Ale co jeszcze ważniejsze, rzeczywistość zazwyczaj nie współpracuje.

Aby zacytować Martellego, „Rzeczywistość nie zawsze współpracuje.” Wymagania się zmieniają, podobnie jak architektura, projekt i implementacja. Iteracyjny rozwój to właściwa droga. Wdroż coś, napraw błędy, ulepszaj, używaj kontroli wersji, recenzji kodu, stylu kodowania, testowania (jeśli nie testujesz, to prosisz się o kłopoty) i na koniec, ale nie mniej ważne, dokładnie dokumentuj to, co zrobiłeś.

To nie oznacza, że powinniśmy obniżać nasze oczekiwania. Jak zauważył Martelli, „nasze marzenia muszą pozostać wielkie, ale najlepszy sposób na ich realizację to wczesne wydawanie, częste wydawanie.” Kontynuował, pokazując przykłady idealnych architektur, które nigdy nie zostały zaimplementowane, wydane, lub które przegrały walkę z ich nie tak doskonałymi rywalami, w tym, Xanadu vs WWW, TCP/IP vs ISO/OSI, MIT ITS vs UNIX.

Film z prezentacji trwa około godziny, ale naprawdę sugeruję wszystkim, którzy rozwijają oprogramowanie, aby się z nim zapoznali. Nawet jeśli nie zgadzasz się z wnioskami, to świetne źródło informacji. Nagranie prezentacji: http://www.youtube.com/watch?v=gHG9FRSlPxw

Moje duże pytanie po przemówieniu było: „Kiedy „wystarczająco dobre” jest wystarczająco dobre?” Kiedy nadchodzi ten moment, podczas procesu rozwoju, gdy można powiedzieć: „Hej, to czas!” Na szczęście odpowiedź na moje pytanie była już w przemówieniu Martellego, tylko czekała, by zostać zauważona.

Wskazówka: oto fragment artykułu Erica Riesa, autora “The Lean Startup”, Good enough never is (or is it?). To jest jego definicja “minimum viable product.”

„Minimalny użyteczny produkt to ta wersja nowego produktu, która pozwala”

zespół, aby zgromadzić maksymalną ilość zweryfikowanej wiedzy przy minimalnym wysiłku.”

Oto jest! To jest odpowiedź, której szukałem. Wdroż coś, co sprawi, że życie kogoś będzie lepsze, coś co rozwiąże jakiś rzeczywisty problem. Zrób to, jak tylko będzie w stanie, który pozwoli Tobie i Twojemu zespołowi uczyć się od prawdziwych interakcji użytkowników, zbierać prawdziwe dane i otrzymywać prawdziwe opinie. Naucz się radzić sobie z faktem, że użytkownicy żyją w prawdziwym świecie – a ten świat jest niedoskonały. Ale alternatywa jest gorsza; jeśli po prostu poczekasz, aż Twoje oprogramowanie dojrzeje do perfekcji w katedrze, nigdy go nie wydasz.

Doskonałość to proces, a nie stan. Parafrazując Eduardo Hughesa Galeano,  utopia jest jak próba dotarcia do horyzontu, którego nigdy nie osiągniemy, ale to powoduje, że posuwamy się do przodu.