Software Engineering, má rozumné paralely?

Konstantou Software Engineeringu (SE) je jeho dynamika. Snad právě proto hledáme paralely a podobenství v jiných oblastech lidské činnosti — abychom lépe porozuměli jeho zákonitostem, uchopili jeho abstraktní nehmotnost a někdy ;-) i jen našli pevnou půdu pod nohoma.

Nejčastějšími doménami, kam se sahá pro inspiraci a popis jsou: “klasická” architektura a stavebnictví (stavíme sofware), strojní výroba (vyrábíme software) a automobilový průmysl (procesní a automatizovaná výroba od designu po prodej). Tyto paralely jsou hodnotné, protože umožňují průmět, projekci něčeho obecně známého do něčeho, o čem někdy tušíme pouze fuzzy obrysy.

Auta, domy, nebo továrny?

Tak jak jsou tyto paralely přínosné, tak jsou zároveň zavádějící. Což není nijak překvapivé — architektura má za sebou tisíce let vývoje. První automobil vznikl někdy v 19. století. Pokud bychom tedy chtěli srovnávat softwarový vývoj s automobilovým průmyslem, bylo by adekvátnější, kdybychom to dělali s fází, kdy ještě nebyl průmyslem. Tedy v dobách, kdy byly zhruba jasné požadavky, ale každý je implementoval po svém.

Tehdy ještě nebyla žádná standardizace. Postupně vznikala unifikace, normy, automatizace, globalizace. Tyhle tendence lze také vysledovat i v oblasti SE. Ale pořád to každý dělá tak nějak po svém.

Pokud máme k dispozici standardizované komponenty (třeba cihly), lze z nich skládat komplexní řešení. Ale nejen to — dá se také přesně spočítat (s rozumnou odchylkou) koncová cena, v návrhu se dají zohlednit jejich fyzické vlastnosti (např. stabilita cílového řešení) atd. Tohle všecno v SE chybí.

Marnost, samá marnost

Lidé z byznysu už dlouhá léta sní o tom, jak se bude software skládat z jednotlivých “krabiček” (= komponent), ale kromě marketérů, kteří se snaží taková řešení prodat, nejspíš nikdo nevěří tomu, že by to fungovalo.

Z mojí zkušenosti se nejdál v tomto směru dostaly nástroje a systémy z oblasti SOA (a nijak překvapivě, hlavně ty komerční). Do určíté úrovně (abstrakce, či návrhu) lze řešení vytvářet “taháním kostiček a šipek”. Ovšem od této hranice níž nastává, námi vývojáři běžně zažívaná, realita — ty “kostičky” je potřeba naimplementovat a to už jsme na poli klasického softwarového vývoje.

Samozřejmě, hodně by zde pomohla znovupoužitelnost. Ale ruku na srdce — už jste někdy viděli, že by reusabilita fungovala na úrovni komponent? Já teda moc ne. Obvykle bývá problém v governance — dozvíte se, že to není pořeba, není to ve scopu projektu, verzování je zbytečná práce navíc, řešení (zpětné) kompatibility je moc náročné atd. Takže řekněme, že… znovupoužitelnost je hezký, ale teoretický koncept. Zatím. Oni se to lidi časem naučí. Tak jako se naučili stavět domy a auta.

Jiným problémem SE je, že se nezabývá jednou (byť třeba rozsáhlou) doménou, jako třeba stavebnictví, ale zasahuje v podstatě do jakékoliv oblasti. V takovém prostředí se pak velmi těžko extrahují nějaké principy, o které se lze opřít v příštích projektech. Proč asi agilní vývoj neslibuje nic konkrétního, ale spíš něco ve stylu “bude to kvalitní, budeme to neustále zlepšovat, ale nevíme přesně, co to nakonec bude” :-)

Vanitas vanitatum. Byť se někteří z nás věnují SE celý svůj produktivní život a pokud zůstanou zdravými programátory, tak snad i zbytek života; tak z hlediska pomíjivosti je SE stále ještě v dětských letech (ne-li v plenkách). Třeba se za sto let naši potomci a následovníci ohlédnou zpět a budou nás litovat, v jakých krutých a nestabilních podmínkách jsme budovali svá díla. A po dalších staletích, až vznikne nové vědecké odvětví — softwarová archeologie — budou vzdálené generace stát v úžasu nad tím, co jsme dokázali vytvořit holýma rukama. (Anebo taky ne.)

Má to smysl?

Pokud se kruhem vrátím zpátky na začátek — má smysl hledat pro SE nějaké paralely? Myslím si, že ano. Pomůžou s porozumněním komplexních řešení a problémů, na které lidská mysl není designovaná. Ale je potřeba to brát s rezervou… software zkrátka nemá čtyři kola.

Související externí články

• Stavebnictví versus softwarové inženýrství