Hype Driven Development

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.