Mýtus nekódujícího architekta

V poslední době mi trochu chybí kódování a přemýšlím, jestli platí, že nekódující architekt je horší než žádný architekt. Největší nebezpečí nekódujícího architekta vidím ve ztrátě citu pro jemné detaily. Architekt musí mít hlavně kontext, ale udržet si kontext nějakého většího systému znamená, že si holt musí od problému trochu poodstoupit. Jsou to dvě protichůdné síly, které na sebe působí. Poodstoupit si od problému je většinou snazší než si držet cit pro jemné detaily, protože ten nejlépe získáte pokud přímo programujete.

Malá vsuvka, občas mi vstávaly vlasy hrůzou, když během pohovoru kdejaký kandidát na architekta prohlašoval, že jeho představa programování spočívala v přípravě PoC nebo nedej bože zkoušení frameworků. To je dle mého skromného názoru nejlepší cesta k tomu, aby vás začaly vývojářské týmy nenávidět.

Když proto mluvím o programování, mám na mysli to, že si ušpiníte pořádně ruce — což je velký rozdíl oproti tomu rozjet někde HelloWorld a pak prohlásit, že to je ta pravá technologie. Bohužel, aby tohle bylo možné, potřebujete více času než pár hodin týdně. Myslím si, že varování o nekódujícím architektovi vzniklo tím, že práce architekta sklouzla v první řadě k výběru technologií a provádění HelloWorld pokusů.

V GoodData máme dvě role formálně pojmenované architekt. Ta jedna více odpovídá kódujícímu architektovi, protože ten člověk je mnohem blíže scrumovým týmům a jeho odpovědnost většinou nepřesahuje několik služeb. Ten si opravdu ušpiní ruce od kódu hodně často, a u něj by platilo, že nekódování by bylo fatální, protože je součástí dennodenních technických rozhodnutí v nejmenším detailu. Druhá role, které říkáme architekt, už předpokládá, že člověk má představu o fungování systému jako celku.

V mojí práci to třeba znamená, že když stavíme datové centrum v Evropě, mám přehled o tom, jaký to bude mít architektonický dopad, přes různé oblasti systému počínaje bezpečností dat a konče deploymentem. Pro tuhle roli je ten cit rovněž potřeba, protože rozhodnutí typu replikujte data mezi datovými centry, se lehce dělá od stolu s koblihou v ruce, ale má dalekosáhlé dopady na implementaci. Zdá se mi ovšem, že získání toho citu je věcí zkušeností, nikoliv toho, že bych kvůli tomu musel kódovat několik hodin denně.

V téhle roli mi programování spíše chybí, protože to pro mě byla zábava, ale nemyslím si, že je nutností (zatím). Ve většině případů je totiž člověk spíše vyjednávačem, který se snaží, aby se vlk nažral a koza zůstala celá obrazně řečeno. Namísto toho, abyste řešili, jestli použít framework X nebo Y, jestli je lepší používat pro odsazení tabulátory nebo mezery, spíše řešíte návrh a rozšíření systému s ohledem na všechny zainteresované strany — vývojáře, zákazníky, produkt management, podporu, finanční oddělení atp. Doporučoval bych proto místo četby knih typu Sedm jazyků v sedmi týdnech navštívit kurz behaviorální psychologie, vyjednávání a kompromisů, protože o tom ta práce primárně je.