Cestou do práce jsem tuhle poslouchal díl Hanselminutes, který se věnuje provařeným “anti-patternům” jako Copy Paste Programming, Iceberg Class, Copy Folder Versioning atd. – v podstatě je celý díl komentářem k tomuto motivačnímu kalendáři.

Jedním z probíraných antipatternů je i Reinventing the Wheel, který úzce souvisí se syndromem NIH, Not Invented Here. Ten je zhruba o tom, že některé týmy a priori odmítají cizí software s tím, že “nebyl vynalezen zde” a přinesl by víc potíží než užitku. Takové uvažování je zvlášť v agilní komunitě považováno za špatné, za “anti-pattern” a nálepka NIH má náležitě pejorativní nádech. Ale víte co? Čím jsem starší, tím víc NIH chápu.

Software se totiž dělí do dvou skupin – ten z první skupiny funguje dobře a ten z druhé ne. Hranice mezi těmito skupinami je bohužel tenká a často subjektivní a problémem cizího software je, že málokdy lze dopředu odhadnout, do které vlastně patří. Už se mi tak mnohokrát stalo, že jsem si řekl “nebudu programovat nic vlastního, prostě použiju nějaké stávající řešení”, a pak následovalo zhruba tohle:

• Vygooglil jsem si několik řešení pro můj problém
• Zkontroloval licence
• Strávil čas hledáním ohlasů na jednotlivá řešení, abych vyloučil outsidery nebo naopak objevil “hvězdy”
• Zkontroloval další metriky, které mě obvykle zajímají, např. jaká je komunita okolo projektu, jestli je aktivně vyvíjen, jestli se fixují bugy apod.

Nakonec jsem nějaké řešení vybral, nasadil a… a byl zklamán, protože software aplikován na můj konkrétní případ s mými konkrétními požadavky měl nějaký problém. Takže znovu – zkusit dalšího kandidáta, strávit s ním další čas, zjistit, jestli vyhovuje atd. Někdy navíc ani není možné během krátké zkušební doby zjistit, jestli software 100% vyhovuje, což pak může vést ke scénáři, který bych nikomu nepřál, ale který jste patrně všichni někdy zažili. Ke scénáři zvanému noční můra.

Noční můra je, když se ze začátku cizí software tváří schopně, a až časem, velmi postupně, zjišťujete, že řešení vlastně moc nevyhovuje. Ne, nevyhovuje je slabé slovo, po čase zjistíte, že původní řešení z duše nenávidíte. Stalo se mi to u několika zásadních věcí, jako je třeba zvolené CMS pro web, zvolený mikro-framework pro zákaznickou aplikaci, jeden interní systém apod. Ve všech těchto případech nastalo řekněme po roce používání nepříjemné dilema – trpět dál s cizím systémem, zkoušet ho upravit, pokud to vůbec jde, nebo s relativně vysokými náklady migrovat někam jinam? Ale kam? Na “NIH” nebo “IH” řešení?

Čím víc podobných zkušeností jsem udělal, tím víc NIH chápu. Ano, jsou věci, kde NIH považuji za jasný syndrom, např. bych v .NETu rozhodně nezvažoval psát vlastní unit testing framework, ale ani u těchto věcí nikdy neříkej nikdy – třeba Jakub Vrána teď napsal “yet another” minifikátor JavaScriptu, a přesto k tomu měl dobré důvody:

• JSMin měl problematickou licenci
• Dal si tu práci, vyzkoušel několik stávajících řešení, a řada z nich kupodivu obsahovala chyby (viz článek a komentáře)

Ostatně, zkušenost s cizím SW popisuje Jakub takto:

Přiznám se, že cizí knihovny nepoužívám moc ochotně. Nejdřív strávím spoustu času hledáním té, která by mi vyhovovala. Pak často zjistím, že mi stejně něčím nevyhovuje. Když to opravím, pošlu změnu autorovi a on ji přijme, tak čekám na vydání nové verze. Když vyjde, tak musím otestovat, jestli se neporouchalo něco jiného. Cizí knihovny taky často mají závislosti (např. na Javě), které já vyžadovat nechci.

Takže asi tak. Osobně se stále snažím hledat existující software, který by můj problém řešil, a často je to pragmatické – přeci jen třeba naprogramovat celé CMS je tak velká práce, že je výhodnější se občas zavztekat nad WordPressem. Přesto jsem během posledních let svůj vztah k NIH přehodnotil – docela tento syndrom chápu. Software is hard.