Chciałbym nieco rozwinąć temat który został już poruszony przez Mateusza na naszym blogu w postaci postu Blog, Hype i Fake News. Dodać do niego chcę więcej na temat samego Hype Driven Development. Rozwinąć kwestię podejścia do poznawania nowych technologii i wykorzystywania ich w komercyjnych, produkcyjnie działających aplikacjach.
Uczestnictwo na konferencji często wiąże się z poznawaniem nowych rzeczy – to jakiś nowy framework, to jakaś nowa baza danych, to jakiś nowy, hipsterski sposób rozwiązywania konkretnego problemu lub konkretnej grupy problemów. Podekscytowani „fajnością” rozwiązań projektujemy w głowie koncepty, które koniecznie musimy wdrożyć w swoich projektach. W projektach które nie trwają 3, 6 lub 12 miesięcy. Niejednokrotnie tworzone systemy wykorzystywane są przez wiele lat. Aż tak jak części mechaniczne się wyeksploatują – biznesowo czy też technicznie…
No właśnie, technicznie. Podejmowanie decyzji technicznych (architektura, wybór frameworka, biblioteki, bazy danych itd.) to nie raz decyzje „na lata”, które mają znaczący impakt na stworzenie i utrzymywanie projektu. Z czasem okazuje się, że nie przewidzieliśmy kierunku rozwoju oprogramowania (wymagania i wizja ulega zmianie w czasie) i to co sprawdzało się jeszcze parę miesięcy temu, teraz jest utrudnieniem. Takie sytuacje się zdarzają. Gorzej gdy projektu jeszcze nie ukończyliśmy, a wybory były nietrafne i bez argumentacji . Gdy widzimy, że zamiast ułatwić sobie pracę, jest wręcz przeciwnie. A to wszystko tylko dlatego, że ktoś zrobił show prezentując nową noSQLową bazę danych. Ktoś inny się podjarał, a następnie ją wdrożył.
Cykl życia Hype Driven Development
Na podstawie tego co zaobserwowałem, wdrażanie Hype Driven Development w większość przypadków przeżywa bardzo podobny cykl życia. Czasem pewne etapy w porównaniu do innych wdrożeń, nie trwają tyle samo, ale następuje w pewnym momencie taki „przełącznik”. Gdyby rozbić cykl życia, to można go zmapować na podobne etapy jakie przeżywamy my – ludzie – młodość, dorosłość, starość.
Podjaranie
Faza pierwsza (młodość). Następuje po wstępnym zapoznaniu się z tematem. Po prezentacji na konferencji, po zagłębieniu się w nowy hype keyword przeczytany na StackOverflow lub w opisie projektu na GitHubie. Od razu lądujący w notatki jako must have to check. Oczywiście jako profesjonaliści musimy zapoznać się z narzędziem, więc następuje kolejny cykl – dokumentacja, instalacja, konfiguracja, radosne testowanie.
Minęły dwa dni, a pełni entuzjazmu i głębokiej wiedzy nt. niezawodności rozwiązania, chcemy użyć go jako złotego środka na wszelkie bolączki w projekcie. Oczywiście +10 do stacku technologicznego.
To faza nieposkromionego optymizmu i wiary we wszystko co potencjalnie może się nie udać.
Ostudzenie
Faza druga (dorosłość). Stopniowe uświadamianie sobie, że pewne funkcje są trudnie do implementacji lub utrzymania. Narzędzie które miało rozwiązywać problemy i przyśpieszać postęp prac, utrudnia rozwój oprogramowania.
To faza kiedy dociera impuls – „coś poszło nie tak”, „źle podjęliśmy decyzję”. Ale gdy początkowe problemy zostaną rozwiązane na około, a nie jak Pan Bóg przykazał brniemy dalej. Przecież rozwiązaliśmy problemy, nic więcej się nie zdarzy. Wszystko pójdzie jak po maśle. Aż, docieramy do momentu kiedy pytamy sami siebie – …
Co tu się odjebało?
Dosłownie. Mógłbym doszukiwać się w pełni grzecznościowego zwrotu, ale prostota (i słoma z butów) podpowiada mi, że nie ma sensu drążyć tematu w sposób elokwentny. Czyli następuje faza trzecia (starość).
To moment kiedy już wiemy, że jeden młotek nie rozwiązuje wszystkich problemów. Może rozwiązywać pewną ich grupę, ale w naszym przypadku totalnie się nie sprawdza. Generuje problemy, które coraz ciężej się rozwiązuje, a same rozwiązania wymagają niewspółmiernego nakładu pracy – koncepcyjnej, programistycznej, a także tej związanej z testowaniem.
Długi czas wdrażania nowych funkcji oraz usprawnianie aktualnych, generuje koszt finansowy – ktoś musi zapłacić za pracę wykonaną przez zespół programistyczny. Także dyskomfort wykorzystywania źle dobranych narzędzi technologicznych odbija się czkawką nie tylko w zespole rozwijającym oprogramowanie, ale również właścicielom produktu.
Podsumowanie
Podążanie za nowinkami technicznymi i chęć zdobywania wiedzy to podstawa, która jest podłożem do bycia wartościowym programistą na rynku pracy (choć to nie jedyna rzecz). Jednak bezmyślne wdrażanie coraz to nowszych rozwiązań (Hype Driven Development) w projekcie jest niedorzeczne.
Pamiętajmy, że technologia ma rozwiązywać problemy, a nie je stwarzać. Być może, problem z którym borykasz się w projekcie od dłuższego czasu, jest nierozwiązalny w akceptowalny sposób przy użyciu znanych Ci narzędzi. Nagle pojawia się rozwiązanie które idealnie sprawdza się w jednym konkretnym przypadku. To ten moment kiedy być może warto je zastosować. Nie traktuj go jednak jako panaceum na wszystko. Nie bój się wykorzystania kilku różnych rozwiązań/narzędzi. Każde z nich ma swoje konkretne przeznaczenie. Nie bój się korzystać z dwóch, trzech (czy nawet więcej) różnych baz danych – każda z nich radzi sobie lepiej lub gorzej z konkretnym przypadkiem.
Jednak … myśl, spisz założenia i porównuj narzędzia realizujące Twoje cele. Wybierz te, które je spełnia i na tle konkurencji w Twoim przypadku jest najrozsądniejszym rozwiązaniem, a wszelkie podjęte decyzje umieść w Decision Log.
Podoba mi się „Co tu się odjebało?” – coś podobnego opowiadał Sobótka na Programistoku https://youtu.be/_5oXEJ4jdmc?t=57m07s W pewnym momencie dochodzimy do momentu gdzie katapultujemy się do kolejnej firmy 😀
Dzięki 🙂 A Sobótkę sobie zostawiam na dzisiejszy wieczór. Pozdrawiam
[…] Hype Driven Development […]