Termín „cargo kult“ odkazuje na chování obyvatel ostrovů v jižním Pacifiku, kteří se během druhé světové války po pozorování letecky shozených zásob snažili napodobit pozorované chování vojáků v naději, že tím přilákají stejnou odměnu. Při aplikaci na vývoj softwaru cargo kult označuje týmy, které napodobují úspěšné postupy nebo metodiky, aniž by rozuměly jejich účelu nebo kontextu, což vede k povrchní implementaci bez kýženého efektu.
Moje zkušenosti s vývojem softwaru formou cargo kultu
Během svého působení v oboru vývoje softwaru jsem byl svědkem týmů, které „nábožně“ přejímaly metodiky technologických gigantů typu Google nebo Spotify, v naději, že se jim podaří napodobit alespoň zlomek jejich úspěchu. Implementovaly inženýrské postupy společnosti Google nebo model týmů společnosti Spotify, aniž by vzaly v úvahu obrovské rozdíly v rozsahu, kultuře a obchodních potřebách. Tento přístup často vede k frustraci a rozčarování, když se nedostaví očekávané přínosy.
Je důležité si uvědomit, že ne každá organizace funguje ve stejném měřítku nebo má stejné zdroje jako tito giganti. Středně velký podnik, který se snaží napodobit autonomní týmy Spotify, může například narazit na problémy, když postrádá základní kulturu důvěry a vyspělého prostředí DevOps, které Spotify pěstuje.
Tato imitace se vztahuje i na nástroje. Nezřídka se stává, že se tým rozhodne pro distribuovanou architekturu microservices pomocí Kubernetes jen proto, že je to trend mezi předními technologickými společnostmi, a ignoruje přitom režii a složitost, kterou to obnáší. To může vést ke scénáři, kdy se tým potýká s provozními problémy distribuovaného systému, přestože by stačila jednodušší monolitická architektura.
Dalším příkladem je slepé přijetí mantry „move fast and break things“. To, co funguje u Mety s jejím rozsáhlým týmem inženýrů a robustní infrastrukturou, se může ukázat jako katastrofální pro firmu s menší uživatelskou základnou a omezenými zdroji na zvládnutí případných následků rychlých a nekontrolovaných změn.
Tyto zkušenosti zdůrazňují, že vývoj softwaru není jen o procesu, ale také o kontextu a porozumění. Skutečné přijetí procesu se vyznačuje hlubokým pochopením jeho principů a promyšlenou implementací, která zohledňuje jedinečný kontext týmu. Cargo kult se oproti tomu zaměřuje na replikaci na úkor porozumění, což vede k rigidní a neefektivní implementaci procesů.
Jak rozpoznat cargo kult a vyhnout se mu
Rozpoznat cargo kult není tak složité – stačí se zeptat „proč“. Proč právě tento postup? Proč používáme tento nástroj nebo metodu? Pokud odpověď zní „Protože to tak dělá úspěšný tým!“, a ne vysvětlení související s vašimi konkrétními potřebami, můžete mít co do činění s cargo kultem.
V kontextu životního cyklu vývoje softwaru (SDLC) se otázka „proč“ stává mocným nástrojem introspekce a zlepšování. Vezměme si například tým, který přijme určitou agilní metodiku, jako je Scrum nebo Kanban, jen proto, že slyšel, že dobře funguje u jiných úspěšných týmů. Mohou začít pořádat každodenní stand-up schůzky nebo vytvářet nástěnky Kanban, aniž by plně chápali důvody těchto postupů.
Chceme-li identifikovat cargo kult, musíme prozkoumat různé aspekty SDLC:
Návrhové vzory
Použití složitých návrhových vzorů nevhodným způsobem nebo jako univerzálního řešení bez zvážení, zda jsou vhodné pro daný problém, může vést k nadměrnému inženýrství.
Hodnocení kódu
Provádění revizí kódu, protože je to jen zaškrtávací políčko v procesu, a ne proto, že je to příležitost ke sdílení znalostí a zlepšení kvality kódu, svědčí o nedostatku porozumění.
Agilní metodiky
Přijetí komplexních technik řízení projektů bez potřebného rozsahu projektu nebo velikosti týmu, což vede k těžkopádnému nadměrnému řízení.
Microservices
Přechod na architekturu microservices a používání kontejnerových technologií bez zvážení, zda složitost naší aplikace a provozní znalosti týmu takovou infrastrukturu opravňují.
Modely družstev
Kopírování modelu Spotify v naději, že podpoří inovace, ale bez podpory kultury autonomie a rozsahu, v němž se takový model stává výhodným.
Continuous integration / Continuous deployment (CI/CD)
Zavádění postupů CI/CD, protože jde o současný průmyslový standard, bez docenění, jak může tento postup zefektivnit proces vývoje a omezit problémy s integrací.
Continuous delivery
Zavedení kontinuálního doručování, protože to tak dělá Amazon, a ignorování faktu, že naše vlastní podnikání nemusí potřebovat tak časté nasazování a mohlo by mít prospěch z více přizpůsobené kadence.
Testování
Investice do rozsáhlé testovací infrastruktury, která neodpovídá našim okamžitým potřebám ani dostupným zdrojům.
Předcházení cargo kultu začíná vzděláváním. Protilátkou proti cargo kultu je kultura zvědavosti a učení. Týmy se musí snažit pochopit principy, které stojí za postupy, jež přijímají. Klíčová je proto komunikace – pokládejte otázky, diskutujte o postupech a ujistěte se, že celý tým chápe „proč“. Týmy je třeba podporovat v tom, aby pochopily principy, které stojí za jejich nástroji a postupy. Měly by si klást otázky jako např.:
- Proč nám tento proces pomáhá dosáhnout našich konkrétních cílů?
- Jak tento nástroj nebo metoda přispívá k efektivitě a kvalitě naší práce?
- Existují alternativy, které lépe vyhovují našim jedinečným výzvám a souvislostem?
Podporou tohoto způsobu myšlení se týmy mohou vyhnout nástrahám cargo kultu a místo toho přijmout postupy, které jsou skutečně v souladu s jejich cíli, což vede k efektivnějšímu a úspěšnějšímu vývoji softwaru.
Nezapomeňte především na to, že procesy vývoje softwaru je třeba přizpůsobit jedinečnému kontextu, a ne se jimi striktně řídit bez porozumění.
Závěr
Cargo kult ve vývoji softwaru slouží jako varovný příběh, který nám připomíná důležitost porozumění před napodobováním. Na naší cestě vývojem softwaru se snažme kriticky zhodnotit své postupy, přijmout promyšlené osvojení procesů a odolat svodům cargo kultu. Pamatujme, že cílem přijetí procesu vývoje softwaru není jeho doslovné následování, ale usnadnění poskytování hodnoty – a toho nelze dosáhnout napodobováním. Vyžaduje to pochopení, přizpůsobení a neustálé zlepšování.
Autor: Martin Závrbský