You Ain't Gonna Need It (YAGNI) jest pojęciem związanym z inżynierią oprogramowania. W skrócie chodzi o to, by dodawać tylko te funkcje, które są potrzebne. Na przykład jeśli ma się do czynienia z Test-driven development (TDD), pisze się tylko tyle kodu, by przejść testy. Swoją drogą świadczy to tylko o tym, jak istotna jest rola testera (nie chodzi mi w tej chwili o "testera bezpieczeństwa"), ale ja nie o tym. Nawet nie o inżynierii oprogramowania, tylko o zasadzie, że "lepsze jest wrogiem dobrego".
You Ain't Gonna Need It
Jakiś czas temu pracowałem w firmie (bardzo fajnej swoją drogą), w której kilka powtarzających się "sytuacji" bardzo działało mi na nerwy. Zresztą sytuacje te powtarzają się (jestem tego niemal pewien) w większości firm. Sam obserwowałem je wszędzie, choć ich wyjątkowe nasilenie miało miejsce w tej jednej, wspomnianej. O co chodzi? O poszukiwanie rozwiązań idealnych. Takich rozwiązań po prostu nie ma. Tak, ja wiem, że wszyscy mówią, że się nie da, przychodzi ktoś, kto tego nie wie i (...), albo opowieści o blue ocean (Blue Ocean Strategy). Tylko, że nie zawsze jest sens marnować czas. Lepiej jest go zmarnować przenosząc przemyślenia na bloga :)
Moje podejście jest nieco inne. Patrzę przede wszystkim na zadanie (temat/cel) do wykonania i zastanawiam się, jak je zrealizować. Dokładnie tak jak w szkole w zadaniach tekstowych (swoją drogą - pamiętam, że ogromny procent populacji bał się tego typu zadań) trzeba znaleźć dane i szukane, a następnie zrobić (wymyślić, zaprojektować) coś, co te szukane znajdzie. Można też patrzeć na to jak na proces biznesowy (takie drobne zboczenie korporacyjne, zarządzanie procesowe nie jest złe o ile nie zostanie sprowadzone do absurdu poprzez tworzenie opisów procesów dla powitania klienta czy sprzątania biura). Mnie interesuje to, by dany proces realizować sprawnie, powtarzalnie, bez zbędnego wysiłku. IT w tym przypadku pełni rolę usługową i mam tu na myśli nie departamenty IT (zwane już też departamentami wsparcia biznesu), ale mój komputer z zainstalowanymi (lub poszukiwanymi) programami. Nie chodzi o wartości artystyczne czy wsparcie innowacyjności, to po prostu ma działać.
Przykłady? Proszę bardzo. Swój cash flow w chwili obecnej kontroluję w prostym arkuszu kalkulacyjnym. Nie jest to rozwiązanie wybitne, innowacyjne. Nawet nie jest kolorowe i nie ma pięknych wykresów. Ale spełnia swoją rolę. Nie interesuje mnie informacja o każdej wydanej/zarobionej złotówce, tylko na przykład to ile mogę wydać by w razie opóźnień w spływie środków z faktur, mieć środki na uregulowanie stałych zobowiązań. Jeśli będę potrzebował dodatkowych informacji, to zastanowię się nad zmianą narzędzia. W tej chwili jest ono wystarczające do realizacji moich potrzeb.
Teraz w tle działa maszyna starająca się zarazić wirusem (teraz z tej listy: Downadup Blocklist). Jak wygląda moje rozwiązanie? Na razie jest trywialne, składa się z:
- pliku wejściowego zawierającego listę adresów/domen (jedna w linii),
- skryptu w Python, który na podstawie tej listy generuje trzeci element układanki czyli...
- ...skrypt JScript, który automatyzuje Internet Explorer przez COM,
Nie jest to rozwiązanie typu state-of-the-art, tylko raczej coś o statusie works for me. Ono nawet nie jest do końca bezobsługowe, bo skrypt zatrzymuje się czasem, gdy pojawia się dialog przeglądarki (np. jakiś alert, dialog pobierania pliku, błąd certyfikatu), ale swoje podstawowe zadanie, czyli przejście stron z listy, realizuje wystarczająco dobrze.
Czasami jest tak, że dyskusja nad technologią zajmuje pozycję absolutnie dominującą. Tak naprawdę nie wiadomo co ma być robione, ale za to długie godziny poświęca się na burze mózgów roztrząsające pytania jak oraz czym będziemy to nie wiadomo w sumie co robić. Jest to kompletne marnotrawstwo czasu (tym cenniejszego, jeśli jest to mój czas bo w tego typu burzach uczestniczyć muszę). Właśnie to marnotrawstwo było mocnym impulsem do zmiany miejsca zatrudnienia. Ja jestem umysł ścisły, chcę mieć dane i szukane, a nie bliżej nieokreśloną wizję Najwyższego Kierownictwa (TM).
Sama technologia nie zmieni podejścia ludzi, nie uczyni ich też mniej leniwymi. Częstym problemem jest gromadzenie wiedzy w taki sposób, by inni też z niej mogli skorzystać (lub by ją sobie odświeżyć w razie potrzeby). Pamiętam jak we wspomnianej firmie pojawiła się taka potrzeba, by mieć miejsce do "wpisywania krótkich notek o czymś i później móc to znaleźć". Pierwszym szybkim rozwiązaniem było uruchomienie obszaru roboczego w SharePoint. Technologia oczywiście była zła, bo (...), a poza tym Microsoftu. No i niewygodna jest, ale jak będzie wiki, to będzie super. To były już dość odległe czasy, wybór platform był jeszcze ograniczony, więc wykorzystane zostało FlexWiki. Platforma (mimo swoich ograniczeń) była już koszerna, ale wcale nie spowodowało to nagłego zwiększenia aktywności w tworzeniu takiej bazy wiedzy... Nie ważne jak bardzo enterprise ready (kolejne słowo klucz dla wtajemniczonych) byłoby rozwiązanie, baza wiedzy sama się nie uzupełni. Interfejs manualny między mózgiem a bazą wiedzy musi zadziałać.
Podsumowując: jeśli jest jakieś zadanie do zrealizowania warto się zastanowić przede wszystkim na czym ono polega, a nie szukać innowacyjnych metod jego realizacji. Innowacyjność ma sens wtedy, gdy generuje jakąś wartość dodaną. Tą wartością dodaną może być nawet zwykła "frajda" z realizacji jakiegoś pomysłu. Nie jestem jednak w stanie zrozumieć szukania innowacyjności przy tak prozaicznych rzeczach jak (przykładowo) zamiatanie podłogi Może i po długich badaniach można odkryć optymalny schemat ruchów miotłą oraz gęstość włosia miotły idealnej, tylko że celem zamiatania podłogi (w moim przypadku) jest to, by było czysto, a nie patentowanie nowej miotły. Jeśli okaże się, że zamiatanie podłogi jest zbyt pracochłonne/uciążliwe to kupię odkurzacz/zatrudnię sprzątaczkę, bo zamiatanie podłogi tudzież projektowanie mioteł to nie jest mój core business ((Y|I)AGNI). No dobra, przyznam się. Odkurzacz już od dawna mam. Pralkę zresztą też. A o sprzątaczkę toczę boje z Moją Ulubioną Czarownicą przy okresowym większym sprzątaniu :P