Čtyři typy složitosti softwaru

Každý tým vysloví tutéž větu: tenhle systém je příliš složitý. Skoro nikdo ji nerozebere. Věta stlačí několik různých problémů do jedné stížnosti, a pak se na jeden problém nasadí lék určený jinému — obvykle energicky a s přesvědčením.

Složitost softwaru není jedna věc. Brooks ji před čtyřiceti lety rozdělil na dvě: podstatnou a nahodilou. Po dvaceti letech v bankovnictví, podnikových systémech a AI infrastruktuře přestaly dvě kategorie stačit. Tady jsou čtyři.

Složitost byznysu

Neodstranitelná váha samotného problému. Bankovní systémy regulatorní omezení opravdu mají. Pojistné produkty opravdu mají hraniční případy. Logistický systém skutečně musí modelovat sklady, trasy a časy. Realitu zjednodušit nelze.

O téhle kategorii stojí za to vědět dvě věci. První: je jí téměř vždy méně, než se zdá — týmy zjišťují, že podstatného je v systému méně, než předpokládaly. Druhá je důležitější a přeskakuje se častěji: požadavky byznysu nejsou vytesané do kamene. Ve většině případů lze nabídnout dvě nebo tři alternativní podoby téhož výsledku a jedna z nich stojí zlomek toho, co ostatní. Ten rozhovor ušetří víc složitosti než jakýkoli refaktoring.

Strategie: přijmout to, co patří realitě, rovnoměrně to rozprostřít po systému a čas od času ověřit, jestli je omezení pořád omezením.

Složitost nástroje

Složitost, kterou si nástroj přináší s sebou. Spring Boot není váš byznysový problém. Kubernetes není váš byznysový problém. Unity není váš byznysový problém. Jakmile je ale nástroj zvolen, stává se nosným: jeho předpoklady formují všechno, co nad ním postavíte.

Tahle složitost nenese žádnou byznysovou hodnotu a po volbě se odstranit nedá. Je to realita, jak je dána. Obchází se, nebojuje se s ní. Nejvíc bolesti v téhle kategorii mají týmy, které si nástroj vybraly a pak odmítly pracovat tak, jak to nástroj očekává — za framework pak platí dvakrát, jednou volbou a podruhé odporem.

Strategie: volit vědomě a po volbě dojít tak daleko, aby se začaly vybírat silné stránky nástroje místo sporu s jeho návrhem.

Nahodilá složitost

Složitost, která vznikla proto, že někdo neviděl jednodušší cestu. Byznysová hodnota nulová, a podíl na celku bývá největší.

Má jednu nebezpečnou vlastnost, která určuje všechno ostatní: ten, kdo ji vytvořil, ji nevidí. Ne že nechce — nemůže. Zevnitř každá abstrakce ve chvíli přidání vypadala rozumně. Tým přidá dočasnou vrstvu, aby si nezavřel možnosti, pak druhou, aby vykompenzoval první, a nakonec systém nikdo neudrží v hlavě celý. Každý krok dával lokálně smysl. Součet ne.

Proto existuje code review. A proto také často selhává: kdo sdílí předpoklady autora, sdílí i jeho slepou skvrnu.

Strategie: přivést člověka bez emocionální investice do současné architektury. Čerstvý pohled najde nahodilou složitost mnohem spolehlivěji než ti zevnitř a zdůvodněný nesouhlas má větší cenu než souhlas — deset slov proč ne váží víc než dvě stránky proč ano, protože nesouhlas otevírá předpoklady a souhlas je zabetonovává.

Složitost z chybějícího nástroje

Složitost způsobená tím, že nástroj, který by měl existovat, neexistuje. Nejvíc podceňovaná ze čtyř a jediná, které se nedávno změnila ekonomika.

Před AI byly interní nástroje dost drahé na to, aby si organizace na bolest zvykly místo toho, aby ji řešily. Opakovaná ruční práce, nepohodlná předávání, provozní tření — to všechno se přijímalo jako počasí. Cenu nikdo nezpochybňoval, protože alternativou bylo čtvrtletí inženýrského času.

Tenhle předpoklad už neplatí. Unity Bridge zabral jeden večer a proměnil „AI neumí ovládat Unity Editor“ v patnáctiminutový postup. Stejný vzorec se ukázal i v bankovním prostředí: chybějící interní nástroj, postavený rychle, nahradil to, co dřív vyžadovalo měsíce procesu. A efekt se skládá — každý další nástroj je levnější než předchozí, protože ten předchozí se stal součástí toho, čím stavíte.

Složitost nikdy nebyla v práci. Byla v nepřítomnosti správného nástroje.

Strategie: když tým znovu a znovu trpí tímtéž bolestivým postupem, zeptat se, jestli by chybějící nástroj nešel dnes postavit za dny místo za čtvrtletí. Čím dál častěji je odpověď ano.

Čtyři vedle sebe

Kategorie nevznikly kvůli klasifikaci samotné. Liší se přesně v těch dvou osách, které rozhodují o tom, co dělat dál.

Z tabulky plynou dvě čtení.

Načisto odstranit lze jen jednu ze čtyř. Nahodilá složitost je jediná kategorie, kde je odstranění téměř čistý zisk — a zpravidla přináší kladné vedlejší účinky, které nikdo neplánoval. Složitost byznysu a nástroje odstranit nelze vůbec. Dá se ale rozprostřít: tenkou vrstvou přes systém místo hustého chuchvalce na jednom místě. V tom spočívá většina řemesla. Architektura se neposuzuje podle toho, kolik složitosti obsahuje, ale podle toho, jak rovnoměrně je rozložená.

Nebezpečné jsou obě neviditelné. Nahodilá se skrývá proto, že její autor je přesvědčen, že tohle je nejjednodušší možné řešení. Chybějící nástroj se skrývá proto, že bolest už byla přijata jako fakt života. Ani jedna se na retrospektivě neohlásí sama. Obě potřebují člověka zvenčí nebo předem položenou otázku, aby byly vůbec vidět.

Jeden mechanismus mění zvladatelné typy v ten odstranitelný: míchání vrstev vyrábí nahodilou složitost. Byznysová pravidla propletená s transportem, transport s ukládáním — každá taková směs je nová složitost, která nepatří do žádné doménové oblasti. Vrstvená architektura se obvykle podává jako best practice. Přesnější je chápat ji jako důsledek: oddělte vrstvy a podíl nahodilého klesne sám.

A pravidlo, které drží napříč projekty: zaměření na nástroje složitost zvyšuje, zaměření na byznys ji snižuje. Tým, který mluví převážně o svém stacku, nafukuje druhou a třetí kategorii. Tým, který mluví převážně o problému zákazníka, je zmenšuje.

Každý inženýr má termostat

Tohle čtyři kategorie samy o sobě nevysvětlí: proč se dva kompetentní inženýři dívající se na týž systém neshodnou na tom, jestli je příliš složitý.

Každý inženýr má komfortní úroveň složitosti a transformuje úlohu tak dlouho, až té úrovně dosáhne. Nízký termostat zjednodušuje: jeho superschopností je najít nejjednodušší model pod úlohou, jeho selháním je ztratit to, co bylo potřeba. Vysoký nabaluje: unese těžkou zátěž bez námahy a nahodilou složitost zvyšuje, aniž by si toho všiml.

To poslední je ta užitečná část. Vysoký termostat má pásmo necitlivosti: malé přírůstky leží pod jeho prahem vnímání. Jako váha, která začíná měřit od kilogramu, neregistruje gramy — a ty se sčítají. Proto systémy těžknou, aniž by existovalo jediné rozhodnutí, které by kdokoli označil za chybu.

Pásmo necitlivosti vysvětluje i něco dalšího: tým, kde mají vysoký termostat všichni, vyrobí vytříbenou architekturu, kterou zvenčí nikdo neumí udržovat, a upřímně se diví, že nový člověk potřebuje čtyři měsíce, než začne být užitečný.

Nejlepší architektura vzniká, když dva termostaty táhnou proti sobě: jeden nahoru („zahazuješ něco, co budeš potřebovat“), druhý dolů („přidáváš něco, o co nikdo nežádal“). Ne jako fáze revize přišroubovaná na konec, ale jako živý spor během návrhu. Tým poskládaný pro shodu o tenhle přístroj přichází úplně.

Stojí za povšimnutí, jak se složitost ohlásí dřív, než ji lze změřit. Přichází jako narušení harmonie: vějíř možných dalších kroků se zužuje, krajina se uzavírá. Zjednodušení se cítí opačně — možnosti se otevírají, pohyb je zase levný. Není to mystika, ale rychlé odečtení toho, kolik tahů systém ještě dovoluje. Dostaví se dlouho před jakoukoli metrikou a stojí za to mu věřit aspoň natolik, aby se to šlo ověřit.

Na AI asistenty to platí v plné míře a dost ostře. Jejich trénovací data jsou podnikové vzory, vrstvy abstrakcí a design patterns, takže jejich termostat je ve výchozím stavu vysoký. Požádejte o architekturu a dostanete kompetentní odpověď, která je těžší, než úloha vyžadovala. Vědět to je většina té opravy.

Pátý kandidát: jazyk

Je ještě jeden a je podceněný téměř k neviditelnosti: složitost samotného přirozeného jazyka.

Jazyk je nepřesný. Myšlenku je těžké vyjádřit přesně a ještě těžší je rekonstruovat, jaký smysl do slov vložil ten, kdo mluvil. Požadavek pochopený dvěma způsoby dá dva systémy a rozpor vypluje o měsíce později jako vada, které se nedohledá autor. Značná část toho, co se odepíše na nahodilou složitost, začala větou, kterou dva lidé přečetli jinak.

Lék na to není, je kompenzace: nést smysl nosiči jiné povahy. Diagram, náčrt, metafora, rozebraný příklad vedle prózy. Multimodalita jazyk přesným neudělá — zmenší ztráty při přenosu, a to je přesně ta část, kterou řídíte.

Plynou z toho dva pracovní návyky. Kontrolovat porozumění, ne provedení: hlídat, jak někdo implementuje, nemá velký smysl, zato požádat ho, aby popsal problém, který se chystá řešit, smysl má — odpověď odhalí rozpor, dokud je levný. A zastavit rozpracování na osmdesáti procentech: zadání nelze dotáhnout na sto, není potřeba jít dál než na osmdesát a zbývající pětinu je levnější zjistit za chodu než předvídat dopředu.

Proč na tom záleží

Týmy sahají po špatné strategii, protože problém špatně zařadí. Refaktorují, když je skutečnou příčinou chybějící nástroj. Přou se o frameworky, když jde o nahodilé vrstvení. Snaží se zjednodušit byznysová pravidla, která nesou podstatnou doménovou znalost. Výsledkem je vyplýtvané úsilí a zpravidla víc složitosti, než bylo na začátku.

Takže když někdo řekne tenhle systém je příliš složitý, užitečná otázka už nezní „jak ho zjednodušíme?“.

Užitečná otázka zní: s jakou složitostí tu vlastně máme co do činění?

Podle mé zkušenosti se překvapivě velký podíl dnešní inženýrské bolesti ukáže být čtvrtým typem — a většina týmů dosud neví, že taková kategorie existuje.