neděle 24. listopadu 2013

Nechte Conwayův zákon pracovat ve váš prospěch

Nějaký čas zpátky jsme řešili největší technologické problémy (technologický dluh), které nás brzdí v tom, abychom dokázali pružněji a zároveň spolehlivě doručovat nové vlastnosti. Při detailním průzkumu jsme zjistili, že většina technických problémů resp. jejich neřešení je způsobené špatně nastavenou organizační strukturou firmy. Nejenom my v GoodData, ale obecně technologické firmy se snaží, alespoň z mojí zkušenosti, řešit technologické problémy aplikováním jiných technologií, které přináší jiné rodinu problémů, čímž pádem ovšem zakrývají původní příčinu. Tato původní příčina většinou sedí na pozorování, které udělal v 70. letech pan Melvin Conway a je základem zákonu po něm pojmenovaném. V tomto článku si povíme o tom co je to Conwayově zákonu, jaké jsou jeho důsledky, jak může pracovat pro nás i proti nám.


V roce 1968 Melvin Conway popsal následující princip

Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure

Historicky jsme měli jednu code base, kde ležely všechny zdrojové kódy, protože jsme měli i jeden a později dva týmy. Postupně se tento stav začal stávat neudržitelný, protože jsme týmů měli několik a každý z nich měl jinou produktivitu. Nedávalo smysl mít jednu verzovací strategii, když jeden tým dodával nové vlastnosti dvakrát do týdne a jiný jednou za měsíc. Začali jsme postupnou demontáží odlupovat jednotlivé komponenty (služby) patřící daným týmům. Šlo to velmi dobře pro komponenty, které vznikly později, a které měly od počátku jasně definovaný tým. Celý proces začal drhnout ve chvíli, kdy jsme narazily na code base, která byla nějakým způsobem rozdělená, ale protože s ní historicky pracoval jeden tým, neexistovalo jasné rozhraní.

Ten tým vždycky seděl v jedné kanceláři, maximálně ve dvou, a proto bylo rozdělení jenom velmi formální - o existenci nějakých rozhraní nemohla být řeč. Proč si taky patlat s formalizováním rozhraní, když jeho uživatel sedí metr a půl od mého stolu. Na všem jsme přece schopni dohodnout se prostým houknutím přes stůl. Jinými slovy propletenec té původní code base odpovídal tomu, že všichni chlapci spolu "navařili" v jedné místnosti. Při rozplétání špaget jsme vytvořili tým, který se pustil do jejich rozplétání. Povedlo se identifikovat komponenty a rozhraní mezi nimi, podle kterého se začalo refaktorovat. Jak už to tak bývá, provedla se jenom první fáze, potom získaly prioritu naléhavější úkoly.

Po nějaké době začal být tento problém opět akutní a my jsme náš plán uvedli znovu do chodu. Oproti původnímu setupu jsme ovšem refaktor distribuovali mezi několik týmů, kterých se rozdělení týkalo. A nestalo se vůbec nic. Abych byl přesnější stalo se to, že jednotlivé týmy vychrlily seznam nutných závislostí na jiné týmy, kterými podmiňovaly začátek vlastní práce.

V druhém případě navržený design přesně kopíroval komunikační strukturu organizace - několik týmů, které vytvořily seznam nutných úkolů. V prvním případě jsme měli jeden tým, který dokázal operovat bez výrazné participace zbytku. Asi není potřeba zdůrazňovat, že druhý přístup - jeden společný cíl s distribucí vzájemně závisejících úkolů mezi více týmu - je mnohem složitější na provedení. Nevím jaká je vaše zkušenost, ale to moje mi říká, že druhý přístup málokdy funguje. Už jenom protože udržet úroveň potřebné komunikace bude složité.

Pokud by existoval jeden ad hoc tým, do kterého by se vybrali zástupci jednotlivých týmů za komponenty, věřím že by vznikly jasně definované komunikační kanály, které by zajistily, že celá práce (design v širším slova smyslu) neskončí ve slepé uličce. Na tomhle případu vynikne Conwayův zákon hned dvakrát. Za prvé, struktura code base přesně kopírovala to, že spolu seděli programátoři v jedné kanceláři - komunikace přes rameno. Za druhé, design řešení problémů, porcování code base, odpovídal struktuře týmů a to jak spolu komunikovaly - výměna úkolů.

Conwayův zákon může pracovat ve váš prospěch. Pokud znáte předpokládaný design systému, na který míříte, můžete vytvořit týmy, které budou tento design kopírovat. To se netýká jenom začátku, ale prakticky jakékoliv fáze vývoje. Představte si, že bude chtít mít striktně oddělený frontend a backend, pak asi nejlépe vytvoříte dva týmy - jeden čistě backendovy a jeden čistě frontendový. Tímhle rozdělením dosáhnete vzniku rozhraní, které bude přesně kopírovat to, že máte dva týmy. To stejné může platit, když budete chtít dělat architekturu orientovanou na služby. Pak vytvoříte týmy, které budou kopírovat jednotlivé služby.

Ways must be found to reward design managers for keeping their organizations lean and flexible. There is need for a philosophy of system design management which is not based on the assumption that adding manpower simply adds to productivity

To byl ještě jednou Melvin Conway a tento výrok se datuje do dob, kdy byl život většiny signatářů Agile manifestu ohraničen kolébkou, dudlíkem, plenkami případně houpacím koněm. Každý systém se mění a tomu by měla odpovídat i změna organizační struktury. V GoodData jsme tuhle zkušenost udělali několikrát ať již při přechodu k architektuře orientované na služby a nebo při přechodu na DevOps. Systém nám přestal škálovat lidsky a technicky. Lidsky neškálovat znamená, že dodání nových programátorů nemá odpovídající dopad na produktivitu. Technicky neškálovat znamená, že s přidáním zdrojů nedošlo k zvýšení výkonu. Postupem času jsme metodou pokusů, omylů a částečných vítězství došli k tomu, že architekturu systému je úspěšně možné změnit jenom pokud jí odpovídá organizace týmů. Nemůžete říkat, že děláte DevOps když máte dvě oddělení - Dev a Ops.

Melvin Conway byl nejenom skvělým pozorovatelem, ale i vizionářem, který přesně popsal vztah mezi organizací a její strukturou a architekturou (designem), který je tato organizace schopna vyprodukovat. Jeho odkaz leží v tom, že systém a jeho změny musí jít ruku v ruce se změnami organizační struktury.

Poznámky