Category Archives: Knihovnička SE

Sníme v kódu

Software is hard. [Donald Knuth]

Tak jsem tu zas s další pidirecenzí knihy pro úchyly jako jsem já a doufám že i vy. V originále se jmenuje Dreaming in Code, a napsal ji Scott Rosenberg. Její podtitul mluví za vše: „Dva tucty programátorů, tři roky, 4 732 chyb a jedna výprava za výjimečným programem.“
O čem, že to je? Pan Mitchell Kapor, zakladatel Lotusu, si vydělal nějakých sto milionů dolarů na Lotusu 1-2-3. No a jelikož nevěděl co s penězi, tak se rozhodl, že založí Open Source projekt, který vyřeší jeho a ostatně i naše trable s MS Outlookem. Že napíše něco mnohem lepšího. Program, který změní svět. Který úplně převrátí náš pohled na na PIM programy. Převratný programu Chandler. Že jste o něm nikdy neslyšeli? Není divu. Ono se to moc nepodařilo. O to je ta kniha zajímavější.
Autor po tři roky sledoval marnou snahu týmu, tento program napsat. A musím přiznat, že je to čtení jen pro silné nátury. Je to čtení o tom, jak se neustále dohadovali, co vlastně chtějí naprogramovat, jak to chtějí naprogramovat, co to bude dělat, jak to bude vypadat, jaké knihovny použít. V prvním roce v podstatě nenapsali nic užitečného. K první použitelné verzi se blížili asi po třech letech! To už to ovšem autor knihy vzdal a šel dělat něco užitečnějšího. Podobně otřesný zážitek jsem zažil naposled, když jsem sledoval Sin City ve Francouzštině.
Co knihu dělá stravitelnou a i užitečnou jsou citace a četné odkazy na další literaturu. Autor často odbočí, problémy Chendleru zobecňuje a píše, co o problému kdo zajímavého napsal. Takže, až vás příště budu ohromovat nějakým citátem, tak víte, kde jsem ho našel.
Takže abych to shrnul, pokud vás zajímá vývoj software, máte silný žaludek a nemáte dost odstrašujících příkladů z vlastní praxe, kniha Dreaming in Code je pro vás ta pravá. Dávám jí chabých 6 hvězdiček z deseti. A dovolte mi zakončit citátem, který knihu docela vystihuje. Jde o odpověď, kterou dal Linus Torvalds na otázku, jakou radu by dal lidem, kteří se pouštějí do velkého projektu.

Nikdo by se neměl pouštět do velkých projektů. Začněte s malým, triviálním projektem a nikdy neočekávejte, že bude velký. Když to budete čekat, jenom ho předimenzujete a budete si myslet, že je důležitější, než pravděpodobně v dané fázi je. Nebo ještě hůř, představa té hromady práce vás může úplně odradit. Takže začněte v malém a myslete na detaily. Nemyslete na velký obraz a fantastický design. Pokud to neřeší okamžitou potřebu, je to zcela jistě předimenzováno.

Nádherný kód

Půl roku v laboratoři vás dokáže uchránit od deseti minut v knihovně.

Původně jsem chtěl psát o svých pokusech se Spring OSGI modulem, ale přišlo mi lepší počkat si, až se ve středu něco poučím na CZJUGu. Takže vás dneska čeká další z mých minirecenzí knih. Tentokrát budu psát o hardcore koderské knize s názvem Beautiful Code. Autora neuvádím, protože co kapitola, to jiný autor. Jde v podstatě o kompilaci textů různých programátorů. Všichni se zamýšlí nad tím, co to je nádherný kód.

Nápad je to dobrý, nicméně takto sepsaná kniha má i své mouchy. Není konzistentní, takže některé kapitoly mě hodně bavily, jiné zase vůbec. Například kapitola o tom, jak funguje přenos dat v Subversion je hodně zajímavá. Stejně tak kapitola o MapReduce. Na druhou stranu, z některých kapitol jsem přečetl jen první dvě stránky a pak je přeskočil.

Samozřejmě, že se v té knize člověk nedozví, jak napsat nádherný kód. Zajímavé ale je, že spousta autorů sdílí názor, že nádherný kód = jednoduchý kód. Několik odvážlivců si dokonce píše i o tom, že nejlepší kód je ten, který vůbec nenapíšeme. Docela s nimi souhlasím, bohužel ne vždy se tím řídím.

Takže abych to shrnul: z knihy mám rozpačitý pocit. Vůbec by neškodilo, kdyby byla poloviční. Je ale možné, že někomu jinému by se líbily jiné kapitoly. Takže uděluji slabých 5 hvězdiček z deseti.

Vytíženost

Chtěl bych se vrátit ke knize Slack, o které jsem tu už psal. Tenkrát jsem si vybral kapitolu, která se mě tehdy docela dotýkala. Bohužel z ní nebylo vidět, o čem ta kniha je. A to je škoda, protože Slack je jedna z nejlepších knih, kterou jsem o managementu četl (ono jich zas tolik nebylo).

Název Slack by se dal podle slovníku přeložit jako časová rezerva, nevyužitý nebo dokonce flákat se. O tom všem to je – o potřebě určité volnosti. Jako příklad uvedu citaci

Vezměte si například sekretářku (Pamatujete si ještě sekretářky? Kdysi obvyklý prvek firemního života.) Práce sekretářky […] usnadňuje hladký průběh pracovního života manažera. Říkejme ji Silva.

Dobrá sekretářka je poklad […] Když je v práci Silva, všechno jde snadno. […] Teď si představte, že nastoupí konzultant s cílem snížit náklady. „Cože, co to je? Sekretářka? A co zrovna teď dělá?“ Sedne si se stopkami vedle jejího stolu. Nikoho nepřekvapí, že přijde na to, že Silva je zaměstnána jen 43% času. Ve zbytku doby se … je k dispozici. Je k dispozici dělat práci kterou zrovna teď potřebujete. To je to co je na Silvě tak skvělé. Když je něco potřeba, je okamžitě k dispozici.

Triumfální výraz se usadí na konzultantově tváři. Pokud je Silva zaměstnána jen 43% času, můžeme ušetřit 57% procent jejího času. Můžeme ji hodit do „poolu“ a alokovat 43% pro vás a 57% pro ostatní. […] Nebo se jí úplně zbavit a najmout brigádníka jen na těch 43%. […] Jaká úžasná efektivnost. Místo člověka který 57% času zahálel, máme někoho kdo pracuje 100% času. Povídejte mi o výkonnosti!

Problém je samozřejmě v tom, že teď plně využitá sekretářka jednoduše nereaguje tak rychle jako Silva. Tato nově výkonná osoba prostě nereaguje tak rychle na věci, které je potřeba udělat, protože má moc práce.

Platí něco podobného o programátorech? Když přijdete na to, že potřebujete 73% programátora, můžete hodit ten zbytek do „poolu“ k dispozici jiným manažerům? Když potřebujete 100% senior programátora, můžete počítat s tím, že ho budete mít na 100%? Co když bude potřebovat poradit nováčkovi, co když bude potřeba řešit něco na projektu na kterém už dávno oficiálně není? Co když bude potřeba pomoci s nabídkou pro nového zákazníka?

Představte si firmu, kde může manažer říci, „Já potřebuju Tondu jen na 50%, zbytek dávám k dispozici, ať si ho veme kdo chce“. Může to fungovat?

Podle mě ne. Za prvé, ten manažer ho nechce jen na 50%, on ho chce jen na 50% platit. Nevěřím, že pro něj bude práce přesně na 4 hodiny denně. Spíš bych tipoval, že víc.

Navíc mám pro vás jednu novinku, programátoři se nedají krájet. Když si z programátora ukrojím půlku, dostanu dvě půlky mrtvoly. Když to udělám jen obrazně, dopadne to jen o trochu lépe. Takže opakuji: 1 programátor – 0,5 programátora << 0,5 programátora. Platí rovnice, kterou se opět můžeme dočíst v knize (od které jsem se na moment trochu odchýlil, za což se všem postiženým omlouvám) Trest za přepínání úloh = čas potřebný pro přesun na novou úlohu + oprava chyb způsobených nevhodným přerušením v práci + čas pro opětovné se ponoření do úkolu + frustrace + ztráta vazby na tým

Takže jak to dopadne v naší hypotetické firmě, která umožňuje prodat dvě půlky programátora? Napadají mě dvě možnosti. Buď budeme potkávat na chodbách usínající programátory, kteří pracují na 150% procent. Nebo se prostě a jednoduše budou falšovat výkazy, tak aby to vypadalo, že máme dvě nezávislé půlky programátora.