Často jsem lidem říkal příběh o tom, jak moc špatně to může dopadnout, když vývojáři aktivně vytvářejí technický dluh a business lidé tlačí na přidávání dalších a dalších nesmyslných funkcí. Svou oblíbenou hlášku „… a jednoho dne přijde okamžik, kdy pro samý technický dluh nebudete schopni provést ani trivialní změnu aplikace a veškerou energii budete pálit na fixování defektů.“ jsem bral jako záměrně přehnanou nadsázku. Dokud jsem neměl tu čest spolupracovat se společností Sinking Ship, s.r.o…

Nasledující řádky popisují reálnou situaci v reálné společnosti. Přesto, že celý příběh může působit lehce apokalypticky, popisuji zde pouze skutečné situace tak, jak jsem jim byl svědkem. Doufám, že nikdo z vás, kdo tento článek čte, v podobné situaci není. Je ale možné, že některé jednotlivé problémy se objevují i ve vaší společnosti. Berte to, prosím, jako popis stavu, ve kterém můžete skončit, když budete problémy příliš dlouho ignorovat.

Společnost Sinking Ship s.r.o. se svojí dlouhodobou obchodní a technologickou strategií dostala do bodu, ve kterém skutečně veškeré usílí vývojářů primárně končilo na hašení urgentních problémů. Vytížení bylo tak velké, že zde už nezbýval žádný čas na jakákoliv systémová řešení. Alespoň podle lidí, kteří tam pracovali. Občas se podařilo managementu protlačit požadavek na nějakou featuru. Ta ale byla vždy do aplikace víceméně vhackována a stala se zdrojem nových problémů. Obvykle okamžitě poté, co byla poslána do produkce. Stav věcí byl všemi technickými pracovníky přijat jako standard a pocit, že to jsou právě oni, kdo hrdině hasí požáry, v nich dokonce vytvořil pocit absolutní nenahraditelnosti a heroismu. Stali se odborníky na chaos, který každým dnem rozšiřovali.

V průběhu práce s touto společností jsem zachytil několik vzorů v přístupu a myšlení celé společnosti a některých důležitých lidí. Seznam vzorů není úplný. Popravdě byly jich desítky. V tomto článku zmíním pouze takové, které jsem potkal i u jiných projektů.

pattern #1

„Není na to čas“

Asi nejpopulárnější a nejvíce opakovaná hláška software vývojářů na téměř cokoliv smysluplného, co by měli dělat, ale nedělají.

„píšete testy?“ „ne, na to není čas“ „děláte code review?“ „ne, na to není čas“ „zkoušeli jste automatizovat deploy process?“ „ne, na to není čas“ „děláte retrospektivy“ „ne, na to není čas“

a tak dále…

Důvodem, proč na nic nebyl čas, byla potřeba řešit urgentní problémy a defekty nebo hláška, že management stále tlačí pouze na nové featury. Krásná ukázka toho, že když řežeme dříví tupou pilou, tak pro samé řezání nemáme čas pilu nabrousit.

Po krátké době jsem přišel na to, že čas není jen na ty vzletné aktivity jako je psaní testů, ale že jaksi chybí i na to, aby se dodržovaly základní pravidla psaní kódu, commit hlášek a prodiskutování práce s ostatními kolegy. To logicky pouze zvyšovalo počet defektů a celý kolotoč nabíral na velikosti a otáčkách.

Neschopnost kohokoliv z vývojového týmu tento hloupý cyklus zastavit a zamyslet se nad ním, byla asi problémem číslo jedna. Bohužel, nebyl na to čas…

Proč tuto zodpovědnost podsouvám lidem z vývojového týmu? Protože business lidi budou vždy primárně tlačit na pilu, budou vždy chtít nové featury a budou je chtít rychle. Ve firmě, která vydělává peníze na psaní software je úkolem software lidí business lidem vysvětlovat, proč je důležité psát kód kvalitně, investovat čas do psaní testů a refactoringu. Toto je ale téma na samostatný článek.

pattern #2

Náš system je moc složitý a speciální

Kdysi jsem slyšel hlášku, že každý národ si myslí, že právě jeho jazyk je ten nejsložitější na světě. Asi to vychází z faktu, že lidem dělá dobře, když jsou něčím speciální a zvládají něco obtížného. Podobný přístup jsem pozoroval u spousty software společností. Jejich vlastní produkt byl vždycky velice komplikovaný a plně chápat ho mohlo jen pár vyvolených – většinou těch, co stáli u jeho zrodu nebo těch, co ve firmě strávili podstatnou část svého života.

Lidé v Sinking Ship s.r.o. to viděli úplně stejně. Možná ale vlastně ne, jako téměř se vším, měli pocit, že jejich systém je ještě více komplexní a ještě více složitý.

Sinking Ship s.r.o. začala svůj business od píky. Lehce inspirováni někým, kdo už na trhu byl, začali vytvářet službu, která dodavatelům banánů umožnila najít odběratele banánů. To je v principu vše. Nebylo to strukturální lodní inženýrství, neposílali družice do vesmíru, nezkoumali DNA. Vytvořili databázi banánů s přístupem přes web. Nechci snižovat složitost prodeje banánů, ale chci se dostat k jádru věci. Složitost nebyla ve službě, kterou doručovali svým zákazníkům, ale v tom, jak systém navrhnuli a divoce a neřízeně rozšiřovali. Složitost tedy byla 100% v implementaci, způsobená nedostatkem zkušeností, vědomostí, disciplíny, odkládáním jakýchkoliv systémových změn či prostého zamyšlení nad tím, jestli to, co a jak dělají je užitečné.

Katastrofy jsou často výsledkem několika problémů, které se sejdou ve stejný okamžik. Tato souhra ale nemusí být náhodná, určitě se mnou budete souhlasit, že pattern #1 úzce souvisí s patternem #2.

Nedostatek času samozřejmě nedovoluje vývojářům, aby se zdokonalovali ve svém oboru, zkoušeli si nové technologie, postupy a nástroje.

Ponaučení, které plyne z patternu #2 je zjistit, zda-li složitost tkví v službě, kterou software doručuje nebo v tom, jak je software napsán.

pattern #3

Ti noví tomu nerozumí

Stejně jako problém složitosti systému byl tak nějak produktem nedostatku času, tak i pattern #3 „Ti noví tomu nerozumí“ je logickým výsledkem uměle vytvořené složitosti systému.

Osobně si myslím, že tento vzor je ale obzvášť záludný a nebezpečný. Důvodem je fakt, že rozděluje lidi na skupinu nových nezkušených a starých moudrých, ale strašně vytížených.

Ale nechme obecné hlášky stranou a pojdmě se podívat na Sinking Ship s.r.o. Bylo tam samozřejmě několik zkušených matadorů, kteří stáli u kolébky rodícího se projektu. V prvních bouřlivých letech obětovali práci na projektu všechno a všechno technické přišlo skrze ně. Jako každý startup se dostali do bodu, kdy zjistili, že by se všechno mělo nějak víc začit organizovat, a že by bylo dobré přijmout nové lidi. Jenže už v té době byli zkušení zaměstnanci natolik vytížení látáním děr v aplikaci, že neměli čas nové zaškolit. Něměli ani čas jim vysvětlit, jak systém funguje, z čeho se skládá, kdo je za co odpovědný. Noví lidé přicházeli a po krátké době odcházeli plni frustrace z toho, s čím se to vlastně potkali. Případně byli vyhozeni, protože po několika týdnech nebo měsících v kanceláři nic neudělali. Otázkou, proč nic neudělali, se nikdo nezabýval. Nebyl na to čas…

Opět zde byl krásný cirkulární systém, noví lidé přicházeli a odcházeli. V očích těch starých zkušených byli k ničemu a proto pro ně nemělo žádný smysl se jim věnovat. Byla to ztráta času…

pattern #4

Upřímní vyjebávači

Nerad užívám sprostá slova, ale jedno sprosté slovo občas vydá za tisíc slušných. Z výše uvedeného textu byste mohli nabýt dojmu, že ti starší a zkušení vývojáři jsou tak trochu chudáci, co se udřou a co pro firmu udělají první i poslední. Bohužel nejsou. Oni totiž vědí, že dělají svou práci špatně. V dnešní době je pro jakéhokoliv vývojáře téměř nemožné, aby alespoň jednou neslyšel nebo nečetl o věcech jako je clean code, test driven development a tak dále. Zároveň vědí, že rozkopírovávání kodů dál a dál, nesmyslně dlouhé metody, promněné nazvané hello1, hello2, atd. věci jen dál zhoršují.

Proč ale vyjebávači? Protože kdykoliv si sedli s kýmkoliv z obchodníků nebo product managerů a ti po nich chěli edukované odhady, například jak dlouho bude určitý projekt trvat nebo jak moc složité je implementovat nějakou featuru, nebyli upřímní. Ani nemohli. Upřímnou odpovědí vysvětlující, proč i relativně jednoduché projekty trvají tak dlouho, by si sami připravili půdu na to, aby byli vyhozeni. A tak vznikaly různé příběhy, proč něco nejde, proč něco bude trvat hrozně dlouho a tak dále.

Pozor, nezapomeňte, že zde popisuji příběh vývojářů Sinking Ship s.r.o.

Jako konzultant jsem se dostal do pozice, kdy bylo mou povinností své poznatky reportovat managementu. Věřte, že to byla role velice nepříjemná a vytvářela atmosféru emočně velice turbuletní. Pokud jsem si já osobně z celého konzultačního projektu něco odnesl, tak to byl poznatek, že s tímhle se musí pracovat v rukavičkách a s jemností pyrotechnika zneškodňujícícho starou a hluboko uloženou bombu.

pattern #5

Pojdmě to dát do cloudu

Outsourcujeme a nakupujme. Pokud vytváříte aplikaci, která je technicky špatně implementovaná a speciálně pokud tato aplikace zpracovává větší objem dat pomocí databáze, problémy s výkonem vám brzy zaklepou na dveře.

Sinking Ship s.r.o. byla v takové situaci. Prodej banánů je jednoduchá věc, ale banánů se prodává opravdu hodně. Sinking Ship s.r.o. měla velkou část aplikace implementovanou přímo na databázové úrovni. Protože datový model byl extrémně špatně navržen a divoce se rozšiřoval a implemetace databázového API byla ještě horší, problémy s výkonem se řešily každý den. Buď byla služba pomalá nebo nefungovala vůbec. To ale není to, o čem tady chci mluvit. Co bylo zajímavé, bylo to, jak se k tomu stavěli všichni technicky orientovaní zamětstnanci a jak to bylo prezentováno ostatním.

Hlavním důvodem pomalosti podle nich byla samozřejmě extrémní složitost jejich aplikace – pattern #2. Druhým důvodem pak byly neustálé DDoS útoky ze strany konkurenčních firem. Jako nezávislý konzultant a zároveň člověk, který se problematikou DDoS útoků poměrně dlouho zabýval, jsem bohužel nenašel žádné důkazy, že by takový útok probíhal. Viděl jsem requesty přicházející na servery, které byly příliš pomalé na to, aby je stačily obsluhovat. Myslím si, že vývojáři a sysadmini to věděli, také věděli, že jejich databáze má zásadní problém na úrovni datového modelu. Podle patternu #4 – upřímní vyjebávači ale zásobovali vedení příběhy o DDoS útoku, o potřebě nakupování lepšího hardware, prací na pseudo-projektech vlastní implementace partitions na úrovni databáze. V neposlední řadě pak byl připravován plán migrace databáze do cloudu s pocitem, že tam to poběží určitě rychleji.

Faktem, že nákupem nového hardware pro databázi zlepšíte odezvy třeba čtyřikrát, zatímco změnou datového modelu tisíckrát a více, se nikdo nezabýval. Na změnu datového modelu nebyl čas a nákup hardware a migrace na nové železo byla mnohem snazší.

Úžasné bylo, že na diskuze o těchto zástupných problémech a o plánech, jak je řešit, si čas, i přes svou obrovskou pracovní vytíženost, našli. Závěry diskuzí nikdy neadresovaly hlavní příčinu problému a většinou vyústily v utrácení nemalých peněz, za věci, které vlastně nepotřebovali a které dále zvyšovaly komplexnost celého systému.

Management technickým pracovníkům plně důvěřoval, peníze se utrácely, a problémy s výkonem stále zůstávaly. Nikdo se nad tím ani moc nepozastavoval a vždy se našel nějaký dobrý důvod, proč se nic nezlepšilo.

pattern #6

Jsme agilní až to bolí, au…

Sinking Ship s.r.o. o sobě ráda tvrdila, že je mladou a velice agilní společností. Anna byla tahounem agilních ideí. Byla to ona, kdo v minulosti přišel s tím, že chaos musí dostat nějakou formu a musí se pracovat podle nějaké metodiky. To je dobrá idea, jenže Annino pojetí agilního vývoje se stalo dokonalou škatulkou na kocourkovatost celé firmy.

Vybrala Scrum, vypracovala metodické příručky, harmonogramy. Zavedla sprinty a obvyklé rituály jako jsou každodenní standupy, dema, restrospektivy. Všechny nástroje byly na místě… tedy většinou když na to byl čas. To byl první problém. Mít standupy se jim, jako všude, tak nějak docela i dařilo. Retrospektivy naopak byly pořád odsouvány. To ale nebyl ten největší problém. Ten tkvěl v tom, že všem rituálům chyběl skutečný obsah, skutečná komunikace, upřímnost a nikdo nechápal jejich smysl. Nástroje jsou dobrá věc, ale pokud vám uniká princip jejich použití, moc vám nepomůžou.

A tak vývojáři na standupech říkali věci, které chtěla Anna jako scrummaster slyšet. Ona si pak mohla zaškrtnout položku kolečko splněno a pokud si dobře vzpomínám, dokonce to zapsala do jejich wiki systému. Na kolečku nikdy nikdo nemluvil o skutečných problémech, nikdy vývojáři neříkali věci svým kolegům, pouze reportovali Anně. Anna pak s jejich pomocí plánovala Sprint Part #1, Sprint Part #2, Sprint Part #3 a tak dále a nikomu nepřišlo nic divné. Místo odhadů času zbývajícího trackovali čas odpracovaný a nedokončená práce se přelévala z jednoho sprintu do dalšího a tak dále.

Nejroztomilejší byly okamžiky, kdy jsem zmínil, že některé procesy by šly vylepšit. Odpověď byla jednoznačná: „všechno už máme a všechno děláme spravně„. Přesně podle příruček od Anny. Agilní a iterativně smýšlející firma odrazila jakoukoliv možnou změnu s razancí baseballové pálky.

pattern #7

A kde byl management?

Celé to pusobí dojmem, že na vině všemu byli pouze vývojáři. Ale není tomu tak, hlavní příčinou problému byl management společnosti. Nebo spíše fakt, že management ve společnosti Sinking Ship s.r.o. vůbec nebyl. Zodpovědností manažerů je udávat směr, řídit, kontrolovat, motivovat a tak dále. To se ale v Sinking Ship s.r.o. nedělo, místo toho management vytvářel klamný dojem rodinné atmosféry a pohody. Jsem velkým příznivcem horizontálně uspořádaných společností, svobodných firem, agilních projektů, je ale velice důležité uvědomit si, že alternativní modely řízení je možné aplikovat, pokud je striktní hierarchický systém kontroly nahrazen jiným modelem a principy, například osobní disciplínou a kompetentností jednotlivých zaměstnanců. Pokud tomu tak není, nemluvíme zde o funkčním systému, ale neproduktivním chaosu.

V návaznosti na tento článek jsem nedávno jsem sepsal zamyšlení nad agilním managementem a častých chýbách v jeho zavádění a důležitosti Product Ownera jako člověka, který definuje smysluplnost existence firmy.

Pár slov na konec

Název společnosti Sinking Ship s.r.o., stejně jako logistika prodeje banánů jsou smyšlené. Vše ostatní je popis existující společnosti, která se vypracovala z malého startupu na společnost se zastoupením v mnoha zemích a vývojovým týmem distribuovaným do několika geograficky oddělených lokalit. Přestože celý článek vyzněl nejspíš hodně negativně, je zde jedna opravdu obdivuhodná věc – schopnost takových společností prodlužovat svoji agonii…

V tomto článku nechci hledat a popisovat řešení jednotlivých problémů, spíše jsem chtěl vypíchnout vzory, které možná můžete pozorovat i u sebe. Protože v Sinking Ship s.r.o. bylo vše dovedeno do extrému, berte to jako popis toho kam až ignorování některých neduhů může vést. Cesta ven z této situace existuje, jen je potřeba jí dát prostor a alespoň část lidí musí být ochotna měnit už zaběhlé vzory chování.

Článek je k dispozici i v anglické verzi na www.softwaresuicide.com

Úvodní obrázek „Sinking Ship“ od Billa Fredericka, http://williamlewisfrederick.com/ – Thank you!