čtvrtek 18. prosince 2014

CZ Podcast 109 - Apiary

K natáčení dalšího dílu jsme využili nabídku Hagen Human Capital a pozvali jsme Apiary tým, respektive CEO Jakuba Nešetřila a CTO Lukáše Linharta, tedy hlavy pomazané. Naše povídání se netočili jenom kolem REST API, ale zabrousili jsme i do zákulisí startupového života, který nás baví a zajímá.

úterý 18. listopadu 2014

CZ Podcast 107 - Erlang

Jako téma tohoto dílu jsme zvolili programovací jazyk Erlang, který je nejenom vhodný pro psaní telefoních ústředen, ale jak se dozvíte, i pro distribuované systémy a algoritmy. Hostem tohoto dílu byli pánove Jan Chochol, David Kubečka a Luboš Veselý.


úterý 4. listopadu 2014

Když MVP dláždí cestu do pekel

MVP všichni tu zkratku milujeme nebo lépe řečeno to co se za ní skrývá. Minimum Viable Product - to nejnutnější minimum, které musíte dodat zákazníkovi, abyste vyřešili to nejdůležitější, co ho pálí. Zákazník to miluje, protože dostane v nejkratším čase to co chce nebo si to alespoň všichni myslí. Vývojáři to milují, protože se jim to vejde do sprintu a nebo se to dá alespoň naplánovat na menší části. Architekti to milují, protože nedochází k velkému designu a zbytečným rozhodnutím implikujícím změny, které možná nebudou potřeba. MVP je dobrý sluha, ale špatný pán. Snadno se z něj stane jednosměrka přímo do pekla. Není to bída MVP, ale důsledek toho, kam vede jeho nevhodné použití. Tento článek je o tom, jak se vyvarovat určitých úskalí s ním spojených.

Malé mentální cvičení kolem MVP dovedené ad absurdum.Přijde za vámi zákazník a řekne, že se potřebuje dostat z bodu A do bodu B. Chtěli byste navrhnout auto. To je ovšem složité a vůbec, potřebuje to zákazník? Co třeba motorku? Moc složité. Co třeba kolo? Ten zákazník bude jezdit vždycky z kopce. Ani kolo není potřeba, co třeba koloběžku? Bude jezdit vždy v zimě. Co třeba sáňky nebo rovnou lyže? Lyže budou ještě jednoduší a levnější. No možná bychom to mohli ještě zjednodušit. Co mu takhle dát pod zadek igelitový pytel, který vycpeme slámou? To nakonec stačí a voilà máme MVP. Zákazník má sice omrzliny prvního stupně, občas si rozbije hubu, ale MVP posloužilo svému účelu.

Podobné MVP má v podstatě dvě stinné stránky. To co je MVP pro zákazníka, může být noční můrou pro vývojáře z pohledu nějaké další údržby a rozvoje. Pokud si nasekáte do produkce několik MVP vedle sebe, může se jejich udržování podobat průchodu minovým pole. Mnohdy je totiž MVP velmi provizorní řešení. Mnohem horší problém s MVP je ten, že mnohdy zůstává na věky. To znamená, že už se do nich nikdy neinvestuje ani koruna. Slouží svému účelu, ale nikdo už je nedotáhne do požadovaného stavu. MVP je polovičatá práce jejíchž důsledky vás dříve nebo později doběhnou.

Pokud nehodláte udělat MVP a to dále rozvíjet, případně jej úplně zaříznout, je lepší nedělat ho vůbec. Úplně nejhorší situace je, pokud vám hromada MVP trčí v produktu, jako kostlivci ve skříni, kteří se jenom třesou na to, aby na vás mohli vypadnout v tu nejméně vhodnou chvíli, pokud možno dohromady, protože mezi nimi existuje nějaká vazba. Velmi se mi líbí myšlenka, kterou popsal Martin Fowler v článku SacrificialArchitecture. Ta s MVP souvisí na úrovni architektury. V kostce se jedná o to, že každá architektura je poplatná době svého vzniku a měla by mít datum expirace. Po jeho uplynutí by nám nemělo být líto danou část systému vyhodit a přepsat ji s ohledem na aktuální požadavky. MVP se dá dělat dobře, ale chce to velkou kázeň, mějte jí, až se k jeho použití uchýlíte.

  1. Nedělejte MVP pokud je to váš jediný modus operandi. Soustřeďte se na minimální řešení, kdy MVP nebude jenom výmluva pro oklamání akceptačních kritérií a pašování práce nízké kvality.
  2. Nedělejte MVP pokud ho nehodláte dále rozvíjet. Rozvíjet může znamenat úplně předělat a nebo zrušit, počítejte s tím.
  3. Nedělejte MVP stavějící na jiném MVP neboť riskujete efekt motýlích křídel.

úterý 28. října 2014

(Ne)marný boj s technologickým dluhem

Naše řešení je technologicky složité a bylo by složíte, i kdybychom nestříleli sami sebe do nohou. Pokud děláte distribuovaný systém, bude ten systém prostě složitý. Máme složitý systém, který je navíc okořeněný různorodostí jazyků a middlewaru, a proto je důležité bojovat s technologickým dluhem, aby na nás neustále nepadal nějaký kostlivec ze skříně. Nám se to v GoodData daří se střídavými úspěchy. V tomhle článku jsem zkusil sepsat pár postřehů a technik, které jsme vyzkoušeli.


Škatulata, škatulata hýbejte se


Dlouhou dobu jsme měli celé řešení rozdělené horizontálně, kdy si každý tým spravoval svojí vrstvu respektive službu. V tomhle rozpoložení se nám s technologickým dluhem nedařilo moc dobře bojovat a nejenom to. Vázl nám i vývoj regulérních produktových požadavků a to především pokud bylo potřeba týmovou spolupráci. Udělali jsme velký třesk a týmy jsme přestavěli na vertikální. Před reorganizací jsme měli tým erlangových vývojářů, java vývojářů, javascriptových vývojářů a perlových vývojářů. Teď máme týmy, kde je obrazně řečeno jeden erlangista, jeden javista, jeden perlista a jeden javascriptař.

Tohle rozložení, už z podstaty, moc nenahrává splácení technologického dluhu. Nebo lépe řečeno, nepozoruji žádný významný rozdíl. Troufám si tvrdit, že jsme si ověřili, že hýbání lidí zleva či zprava nemá na technologický dluh žádný vliv (přestože to nebyl hlavni cíl reorganizace).


Přiznejte si, že máte problém a ten kvantifikujte ho

Je to jako na sezení anonymních alkoholiků, tedy ne že bych tam někdy byl, musíte si nejprve přiznat, že máte nějaký problém. My jsme si udělali seznam s popisem jednotlivých oblastí a určili jsme si jejich priority. Seznam nám visí na vstupních dveřích kuchyňky, aby ho nikdo nemohl minout - viditelnost. Důležité je, že je to něco konkrétního, kvantifikovatelného, nejenom něco abstraktního.


Shoda, že s dluhem hodláte něco dělat

Důležitá je shoda s managementem, že je v zájmu všech s dluhem něco dělat. Management má někdy tendence tyhle problémy bagatelizovat, proto je důležité vysvětlovat, vysvětlovat a zase vysvětlovat a to i opakovaně. Technologický dluh nezmizí mávnutím kouzelného proutku. Alergie managementu na jakoukoliv zmínku o technologickém dluhu vyplývá ze snahy inženýrů vždy a za každých okolností se na něj vymlouvat. Právě proto se musíte shodnout, že s ním chcete bojovat.


Boj musí být priorita

Každý kvartál začínáme se seznamem priorit, na které se budeme zaměřovat. Pokud se nám tam nedostal konkrétní bod z výše uvedeného seznamu, nikdy se nic nestalo, dluh zůstal dluhem. Dávat si za prioritu cíl bojovat s technologickým dluhem nestačí. Vyberte si konkrétní bod ze seznamu, se kterým chcete bojovat a tomu dejte stejnou prioritu, jako produktovým požadavkům. Ve scrumu jsme zkoušeli rezervovat část kapacity týmu, ale i to nemělo zářné výsledky. Pocitově mi přišlo nejlepší, když byl celý sprint dedikovaný právě na konkrétní oblast technologického dluhu.


Vlastnictví

Technologický dluh se často obnaží v místech, které jsou vlastněné všemi a zároveň nikým. Je to podobné, jako s kurtizánou, se kterou obcuje půlka fotbalového mužstva, a když otěhotní, nikdo se k tomu nemá, protože to může být kohokoliv. A je úplně jedno jestli se jedná o část code base a nebo nějakou sdílenou službu. Jasné vlastnictví umožňuje lepší plánování a alokaci zdrojů. Pokud není možné určit jednoznačného vlastníka, musí se daná věc nějakým způsobem rozsekat. Pokud to není možné, většinou to indikuje nějaké nezdravé závislosti. Jejich rozmotání bývá často zdrojem všech problémů.


Trpělivost

Obrňte se trpělivostí, protože splácení technologického dluhu je běh na dlouhou trať. Boj s větrnými mlýny je to ve chvíli kdy máte nejasné vlastnictví, kolidující priority a zároveň musíte hasit požáry. V tom případě začněte od začátku výše uvedeného seznamu.