.st0{fill:#FFFFFF;}

Worse is better 

 16 września, 2020

Łukasz Bręk

Teorii tego typu jest wiele, jednak ta jest wyjątkowa. Znacie polskie przysłowie „Nadgorliwość jest gorsza od…”? Worse is better każe się zastanowić, czy nie powinniśmy naszych wysiłków przenieść gdzie indziej. Może będzie miało to większy sens?

 

„Teoria teorią, my i tak wiemy swoje”

Teorii w programowaniu jest bez liku. Opisywana dziś jest jedną z dziesiątek, jednak jej nazwa wyjątkowo przykuła moją uwagę. Może dlatego, że kiedy ją zobaczyłem od razu pomyślałem o pragmatyzmie. I o tym, żeby się nie narobić.

To też groźna nazwa, bo zrozumiana opacznie sprowadzi nas na manowce. Bo co oznacza „Worse is better”? Czy powinniśmy zadowolić się czymś niedopracowanym, złym, irytującym? Ani w tej, ani w żadnej innej teorii tego typu, o to nie chodzi. Jak więc zidentyfikować stronę, w którą powinniśmy podążać?

Odpowiedzią są dobrze wszystkim znane 3 literki, pod którymi kryje się cała magia. Nie jest to jednak tekst o MVP. Wracając do teorii Worse is better mów wprost:

„W programowaniu 'right now’ (właśnie teraz) jest znacznie ważniejsze od 'right way’ (właściwego sposobu)”

Już słyszę te oklaski i peany. W końcu jest teoria, z którą zgodzą się PRAWIE wszyscy.

 

Dług technologiczny

Nie czuję się na siłach, aby podważać istniejące teorie. Tym bardziej, że zostały one pewnie wymyślone przez mądrzejszych niż ja. Zastanawia mnie jednak, co się stanie, jeśli podążać będziemy zgodnie z tą przedstawioną powyżej. Pomijając tę oczywistą rzecz, o której już napisałem (powolne podążanie do upadku) naturalną konsekwencją będzie powstanie długu technologicznego.

Dług ten jest świadomie podjętą decyzją w zakresie rezygnacji w chwili obecnej z wymaganego elementu (np. wydajność) na poczet jego realizacji w przyszłości. „Właśnie teraz” jest ważniejsze od „właściwy sposób”. Mi pasuje.

Skoro tak, to może zawsze powinniśmy postępować właśnie w ten sposób? I tak, i nie. Podejmując decyzję, również w kontekście długu technologicznego, zawsze musimy wziąć pod uwagę wszystkie niezbędne zmienne, a jedną z nich będzie w tym przypadku nasz interesariusz. Może on powiedzieć „ma być i kropka”. W ten sposób nie ma śladu po długu technologicznym i teorii „Worse is better”.

Zawsze jednak na końcu stoi Product Owner i jego maksymalizowanie wartości produktu. Product Ownerze do boju, pokaż klientowi, że się myli, że robiąc coś w inny sposób dostanie więcej.

 

„Worse is better” w praktyce

Nie zastanawiałem się nad tą teorią wcześniej. Od jakiegoś miesiąca miałem ją na tapecie jako post do napisania, ale nie zastanawiałem się w jaki sposób można ją wykorzystać. Albo jaki przykład wykorzystania opisać aby ukazać, że faktycznie działa ona zgodnie z założeniami. I w tym momencie z pomocą przyszła mi uwielbiana przez wszystkich Wikipedia.

Otóż okazało się, że miała ona swego czasu (choć trudno w to dziś uwierzyć) prekursora o nazwie Nupedia. Cechą charakterystyczną prekursora było to, że każde z haseł opisywane było przez specjalistę w dziedzinie. Można więc domniemywać, że każde hasło było opisane w sposób zbliżony do perfekcji, mogło to również prowadzić do tego, że wiele z nich nie zostało ukończonych nigdy. Musiało być to czaso i kapitałochłonne. Jak działa Wikipedia? Poszczególne hasła mogą być i są opisywane przez kogokolwiek posiadającego wiedzę, co powoduje, że jakość pierwszych wpisów dotyczących danego zagadnienia może być niska. I to pomimo „opieki” ze strony edytorów.

Jaki jest jednak finalny obraz tego pojedynku. Wikipedię zna każdy, o Nupedii słyszeli nieliczni. Szybko okazało się również, że ilość bardzo dobrze opracowanych haseł w Wikipedii jest kilka razy większa niż ilość bardzo dobrze opracowanych haseł w Nupedii. Na tym właśnie zakończono projekt w przypadku drugiego z portalów.

 

Worse is better?

Podsumowanie to miejsce, w którym zawsze piszę o słuszności teorii. Nie inaczej będzie tym razem. Zresztą kto mnie zna doskonale wie, że jestem gorącym zwolennikiem pragmatyzmu. Tego dobrze rozumianego oczywiście. Zastosowanie teorii Worse is better w dobry sposób spowoduje, że mamy możliwość odniesienia sukcesu – niczym Wikipedia.

Zastanawia mnie zawsze po co rzucać się na głęboką wodę, po co robić wszystko od razu. Czy nie robimy tego tylko dlatego, że ktoś tego wymaga nie mając świadomości jakie są konsekwencje jego decyzji? Może przedstawienie historii Nupedii i Wikipedii pozwoli na zrozumienie drogi, którą powinniśmy obrać. Do zaryzykowania mamy całkiem sporo. Ryzykujemy projektem, czyli przede wszystkim ludźmi, którzy są zaangażowani w jego realizację. Po drodze mamy jeszcze czas i pieniądze.

Łukasz Bręk


15 lat doświadczenia w IT, 8 lat doświadczenia w metodykach zwinnych, PSM, PSPO, Scrum Master zespołów zwinnych, Product Owner, analityk biznesowy/systemowy, Agile Coach, trener Scrum.
Swój warsztat szlifował na projektach waterfallowych, dziś skupiony wokół zwinnego dostarczania Produktu.

Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}