Dowody a kryterium sukcesu

Jak dostarczyć dowody pokazujące, że zrobiliśmy coś prawidłowo, bądź nie? Jak udowodnić, że nasze rozwiązanie jest lepsze? W pracy inżyniera dowody mają kluczowe znaczenie. Tu z wielką pomocą przychodzi nam mierzenie.

Niezależnie od tego, jaki problem rozwiązujemy, pojawia się zawsze kilka podstawowych pytań:

  • Jakie są kryteria sukcesu?
  • Jakie są kryteria porażki?

Wbrew pozorom nie są to proste pytania, ale definitywne warto poznać odpowiedzi na nie, zanim ukończymy projekt. :)

Bardzo ważne jest zrozumienie, co tak naprawdę musi się stać, by uznać, że odnieśliśmy sukces. Innymi słowy – po czym poznamy sukces.

Jak w danym momencie trwania projektu jesteśmy w stanie określić naszą aktualną odległość od sukcesu?

Mierzenie podstawą sukcesu

Wyobraźmy sobie samochód. Czy możemy przyspieszyć? Musimy spojrzeć na prędkościomierz – jeśli jesteśmy na autostradzie i jedziemy 60 km/h, powinniśmy przyspieszyć.

Bez prędkościomierza trudno podjąć decyzję o przyspieszeniu. To, co nam pomaga, to kwantyfikacja – umiejętność określenia wartości liczbowej, która pomaga nam w podjęciu decyzji.

Tak samo w procesie tworzenia czegokolwiek kluczowe jest to, by nie tylko wiedzieć, czym jest sukces, ale też ujmowanie kwantyfikatów składowych tego sukcesu. Mierzenie jest bardzo istotne, bo pomaga nam podjąć decyzję – inaczej zachowamy się jadąc 110 km/h na autostradzie, inaczej jadąc 30 km/h.

Nie wyobrażam sobie inżyniera budowy, który określa, czy można zbudować cienką ścianę, nie sprawdzając, czy spełnia wszystkie wymagania w sposób mierzalny.

Nie wyobrażam sobie zespołu F1, który podejmuje decyzję o wymianie dyfuzora w bolidzie na lepszy na bazie opinii: “na pewno będzie lepiej”.

Istotne są zatem miary sukcesu, którymi można się podeprzeć, by wiedzieć, czy naprawdę jest lepiej.

Załóżmy czysto teoretycznie, że celem zespołu jest zwiększenie prędkości jezdnej bolidu. Jak sprawdzą, czy po wymianie elementu jezdnego pojazd porusza się szybciej? Zmierzą prędkość. Jeśli to jedyne kryterium i pojazd jeździ szybciej, to osiągnęli zamierzony sukces. Jeśli pojazd porusza się wolniej, to mają podstawy, by odrzucić zmianę.

Jak to zweryfikują? Po prostu, odczytają wartość z prędkościomierza. Jeśli poprzednia prędkość wynosiła 340 km/h, a obecna wynosi 341h/m, to chyba każdy może stwierdzić, że jest zauważalnie większa.

Ale czy prędkość maksymalna 341 km/h, przy przyspieszeniu o 80% niższym niż przed zmianą, to znaczy “lepiej”? Niekoniecznie. To sprawia, że bardzo ważne jest określenie wszystkich istotnych wartości, na których nam zależy. W innym wypadku podejmiemy decyzję na bazie fałszywych przesłanek – 341 km/h to “lepiej” niż 340 km/h. Jeśli przeoczyliśmy zmianę w przyspieszeniu, pogorszyliśmy sytuację, nie wiedząc o tym.

Czego potrzebujemy, by mierzyć?

Samo mierzenie nie gwarantuje nam sukcesu.

Podam Ci liczbę 50 km/h. To mało, czy dużo? Osiągnęliśmy sukces, czy też nie?

Potrzebujemy informacji, jaki jest stan poprzedni, cel oraz kierunek zmiany.

Jeśli mamy informacje o pomiarze 50 km/h, to w przypadku, gdy chcemy przyspieszyć auto, które wcześniej jeździło 49 km/h, to jest to sukces.

Jeśli mamy informacje, że winda przyśpieszyła z 8 m/s do 50 km/h, to już nie wydaje się oczywiste, czy osiągnęliśmy zamierzony cel.

Czym jest w tym wypadku sukces? Co staraliśmy się osiągnąć? Czy to, że winda jedzie szybciej, to dobrze czy źle? Co optymalizowaliśmy?

Jeśli miara powiązana jest np. z poczuciem bezpieczeństwa czy komfortem, a nie z czasem podróży, to należy sobie zadać pytanie, jak zmiana prędkości, która jest wynikiem zmiany silnika, wpłynie na te dwie rzeczy.

Wyobraź sobie, że wsiadasz do windy z dzieckiem. Winda jedzie z prędkością 100 km/h na godzinę (to jest 27 m/s - czyli, jeśli pominiemy fakt, że winda musi wyhamować, to w ciągu sekundy będzie w stanie wjechać na 10 piętro)– jak to wpłynie na komfort jazdy? Czy dziecko zacznie płakać?

Dopiero pełna informacja o tym:

  • Jaka wartość jest dla nas istotna?
  • Jakie miary są powiązane z tą wartością?
  • W jaki sposób je mierzymy?
  • Jaki jest aktualny stan, a jaki jest stan oczekiwany?

Możemy przystąpić do procesu mierzenia.

Mierzenie wymagań

Mierzenie prędkości, mierzenie metrów czy mierzenie kilogramów wydaje się być oczywiste i naturalne. Problemy mogą się pojawić, gdy staramy się realizować bardziej skomplikowane projekty.

Czy faktycznie potrzebujemy mierzyć wszystko i czy wszystko da się mierzyć?

Oczywiście, że się da, ale może to być z początku trudne.

Weźmy jako przykład grupę ludzi, która postanowiła stworzyć grę dla innych ludzi, w którą będą mogli pograć w trakcie imprezy. Polegałaby na oprogramowaniu botów.

Padło kilka wymagań:

  • Serwer gry powinien być szybki,
  • Serwer gry powinien umożliwiać jednoczesną grę,
  • Serwer gry powinien być wydajny,
  • Serwer gry powinien być bezpieczny.

Jeśli usiedlibyśmy i zaczęlibyśmy od razu od pisania kodu, co mogłoby pójść źle? Przyjrzyj się tym wymaganiom wobec systemu. Co widzisz? Te wymagania są bardzo mało precyzyjne oraz pozostawiają dużą możliwość interpretacji.

Weźmy dwie osoby z tego samego zespołu i zadajmy im pytanie: jak interpretują stwierdzenie “szybki” wobec systemu, który piszą? A następnie zadajmy im pytanie: jak mierzą to, czy faktycznie system jest szybszy? Jak wprowadzona zmiana wpływa na “szybkość” systemu?

Niestety, w mojej karierze kilkakrotnie spotkałem się z mniej więcej takim poziomem wymagań, które dostawałem w notce, jak ta powyżej. To sprawiało, że praktycznie nie dało się określić, czego chciał klient.

Zatem, zanim przystąpimy do realizacji zadania, wypadałoby określić, jakie są kryteria akceptacji tego zadania. Dopytać klienta, co on rozumie poprzez “szybki”, “wydajny”.

Zdaję sobie sprawę, że są to buzzwordy, na poziomie mowy biznesu, które zastępują bardziej skomplikowane i złożone pojęcia. Wymagają dekompozycji nawet do kilku mniejszych pojęć, aż do momentu pewności, że możemy już tym posiadanym przypisać miarę :)

Celem dekompozycji jest zejście z poziomu złożonych terminów do poziomu rzeczy, które po prostu możemy zmierzyć i nadać im wartość na jakiejś skali.

Mierzenie buzzwordów

Szybki, wydajny, bezpieczny.

Słowa-wytrychy. Słowa klucze, które są niebezpieczne dla inżynierii, bo nie pozwalają nam wytworzyć czegoś, co możemy udowodnić, że działa zgodnie z wymaganiami.

Potrzebujemy dowodów, które pokazują, że wykonaliśmy naszą pracę prawidłowo i że nikomu nie szkodzimy. :)

Popatrz na taką sytuację:

  • Inżynier A przynosi rozwiązanie w oparciu o RUST. Przetwarza obliczenia w 50 ms.
  • Drugi inżynier przynosi rozwiązanie w oparciu o C++. Przetwarza obliczenia w 49 ms.

Które z tych rozwiązań jest lepsze? Które z nich spełnia wymagania? Którego powinniśmy użyć?

Intuicja podpowiada, że drugie jest lepsze. Inżynieria podpowiada, że nie można na podstawie tych informacji stwierdzić, które jest lepsze bez poznania kryteriów oraz np. kontekstu użycia.

Jeśli przez “szybsze” zrozumielibyśmy czas kalkulacji mniejszy niż 50 ms, to faktycznie drugie rozwiązanie jest lepsze. “Lepsze” oznacza krótszy czas kalkulacji, a dokładniej czas kalkulacji poniżej progu 50 ms.

Ale jeśli przez “szybsze” rozumiemy: “zauważalnie szybsze dla człowieka niż aktualny system”, który ma czas odpowiedzi rzędu dwie sekundy, oba rozwiązania są tak samo dobre - oba spełniają warunek “szybsze”.

To sprawia, że bez określenia, czemu coś robimy, nie da się przeprowadzić sensownej inżynierii.

Inżynieria trzyma się twardych dowodów. Korzysta z liczb, miar. Ewidencjonuje.

Jeśli chcemy wybrać odpowiednie rozwiązanie, to wybieramy takie, które w sposób mierzalny przybliży nas do celu lub pozwoli nam osiągnąć ten cel.

Określenie miar

Wróćmy do naszego przykładu. Jak zamienić buzzwordy w coś, co da się mierzyć. Trzeba zadać sobie pytanie, co dane słowo oznacza w naszym kontekście ?

  • Serwer gry powinien być szybki:
    • liczenie nowego stanu, punktów NIGDY nie powinno zająć więcej niż 100ms
  • Serwer gry powinien umożliwiać jednoczesną grę:
    • jesteśmy w stanie obsłużyć 50 requestów per użytkownika per turę (które będą trwały tak krótko jak 1s
  • Serwer gry powinien być bezpieczny:
    • Tylko osoba mająca token i login może zmieniać stan oraz dopytywać o aktualny stan. Nikt więcej.

Zauważcie, jak bardzo nazwanie rzeczy po imieniu, a dokładniej po metryce, zmienia podejście. Nie ma już szybkości – jest tylko sposób jej mierzenia. Liczenie nowego stanu nie może zająć więcej niż 100 ms. Bardzo precyzyjne. Jeśli mierzymy i przedstawimy pomiar, to ogranicza to możliwość nadinterpretacji.

Jest konkretna metryka. Jest konkretny sposób mierzenia i miara. Jeśli przekroczymy 100 ms, to nie spełniliśmy wymagań. Wszystko poniżej 100 ms – nieważne, czy 40 ms czy 99 ms – oznacza sukces.

Jako dodatkowa premia, informacja, jak coś mierzymy, jest jednocześnie informacją, czym dla nas jest dane zjawisko. W powyższym przykładzie “szybki” oznacza: “nie więcej niż 100 ms”. W wypadku biegu na 100 metrów słowo “szybki” znaczyłoby coś zupełnie odmiennego.

Tak samo inżynier planujący budowę mostu operuje na metrykach. Używa liczb do pokazania sensowności swojego projektu w stosunku do wymagań. Udowadnia, że wykonuje prawidłową pracę i że zbliża się do celu.

“Mój projekt utrzyma 30 ton pojazdów jednocześnie jadących po moście.” “Zachowa się stabilnie przy wietrze 400 km/h.”

Jeśli przychodzi do mnie inżynier oprogramowania, który mówi, że ma lepsze rozwiązanie, które działa szybciej to… mam mu wierzyć na słowo? Tylko dlatego, że od jego rozwiązania nie zależy ludzkie życie? Nie brzmi to jak strategia wygrywająca.

Mierzenie a skomplikowane systemy

Inżynieria systemów staje się jeszcze bardziej skomplikowana, bo przy dziesiątkach interesariuszy mamy do czynienia z wieloma wartościami i miarami.

Dobierając strategie, wpływamy lub możemy wpłynąć pozytywnie,ale też negatywnie na każdą z wartości z osobna.

Mając 100 interesariuszy, mamy najpewniej 1000 wartości. Każda z nich jest istotna dla różnych odbiorców. Wprowadzenie zmian bez przemyślenia, bez dowodów, zgodnie z metodyką yolo (you only live once) może zakończyć się zarówno sukcesem, jak i (co bardziej prawdopodobne) gigantyczną porażką.

Absurd polega na tym, że bez miar nie będziemy w stanie zmierzyć rozmiaru klęski i odległości od sukcesu. Możemy binarnie stwierdzić, patrząc na reakcję odbiorcy, klienta, że jest źle. Lub liczyć, że nie zauważy. Może i tak zapłaci…

Podsumowanie

Miary i mierzenie to podstawa dobrej inżynierii. Określenie, co i w jaki sposób mierzymy, może nas przybliżyć do sukcesu lub pokazać nam, jak daleko od sukcesu się w chwili obecnej znajdujemy.

Dają nam także przydatną informację przed podjęciem decyzji – czy idziemy w dobrym kierunku, czy się zbliżamy, czy oddalamy.

Bardzo ważne jest posiadanie informacji nie tylko o wartości pomiaru, ale także o tym, z czym dana miara jest powiązana. Kontekst jest królem i pozwala zinterpretować kierunek optymalizacji.

Inżynier mostów wie, że zmiana materiałów na mniej trwałe może wpłynąć na: maksymalny udźwig, żywotność mostu, cenę i pewnie wiele innych wartości.

Inżynier oprogramowania często wie tylko, w jaki sposób jego rozwiązanie wpłynie na wykonanie jego zadania – rzadko wie, jak wpłynie na cały system.

Jest to bardzo wygodne w momencie, w którym chcemy się pozbyć odpowiedzialności za system :). Jednocześnie nie jest to inżynieria. Jest to tylko pisanie kodu.