Programování se blbě měří, protože se zásadně liší od manuální výroby nebo stavby baráku. Na tyhle činnosti jsou ale manažeři trénováni (škola, knížky, články, ...), takže chápu jejich frustraci, když všechny poučky, co se naučili, najednou v softwaru neplatí.
Zásadní rozdíl je v opakovatelnosti. Jakákoliv činnost, která se při programování opakuje, by se měla dát odprogramovat pryč. Prostě to, co se opakuje, hodím vedle do funkce. Samozřejmě to platí v nějakém idealizovaném modelu, kde nejsou překážky jako legacy code nebo to, že programátor nemá perfektní přehled o celém kódu, musí pracovat v týmu, apod.
Princip ale zůstává - programátor je tím lepší, čím je línější a odprogramovává si práci pod rukama. Už jenom kvůli tomu nemá smysl jeho činnost měřit jako manuální práci.
Kdyby se přece jenom měla dělat analogie se stavbou nebo výrobou, pak by programátor nebyl ten dělňas u pásu, ale ten, kdo navrhuje výrobní linku. Taky měříte ve firmě produktivitu toho, kdo navrhuje výrobní linku?
Ano, existují firmy, které výrobní linky navrhují a vytvářejí jako byznys. V takové firmě zjistí, že plno výrobních linek je vlastně hodně podobných, takže vytvoří stroje na výrobu komponent výrobní linky. V takové firmě je pak ale programátor ten, kdo neskládá výrobní linky na výrobu výrobních linek, ale ten, kdo je navrhuje.
Existují "programátoři", kterým se říká code monkeys, nebo lepiči, protože pouze tupě aplikují nějakou metodiku a matlají v textovém editoru písmenka kódu dle jakéhosi UML diagramu, který jim poslal jakýsi architekt. To jsou případy firem, které srovnávají programování právě třeba se stavbou baráku. Na světě jsou často jenom proto, že jsou krmeny nějakým státním sosákem nebo jinou too-big-to-fail firmou.
Zdroj této špatné analogie k výrobě a stavebnictví je pravděpodobně ten, že program se (dle manažera) po analýze (prováděné architektem) vytváří programátorem (builder). Přičemž pro programátora znamená build až fázi při kompilování, takže programátor je sám o sobě spíš tím architektem, kdo dodal instrukce. Kompiler je jeho dělňas, kdo za něj vytvořil tvrdou práci. Protože takhle fáze trvá jen pár milisekund, je manažerama přehlídnuta, z čehož musí usoudit, že programátor je vlastně ten dělník.
Manažer se ptá: Ale já potřebuju vědět, jak dlouho to bude trvat! Ptá se zákazník, co mu mám říct??
1. Pokud je to opakovaná záležitost a prakticky chce něco, co už má konkurence, pak se zmáčkne pár čudlíků, nakliká se konfigurace a řešení je na světě. Pokud taková firma ještě neexistuje, pak je to díra na trhu.
2. Pokud je to něco nového, pak nemá smysl se bavit o tom, kdy a za kolik to bude. Pokud je to novinka, pak ani zákazník neví přesně, co chce, a proto musí projít kolečkem vývoje a zpětné vazby, během kterého se ujasní jeho požadavky. Pak nesmlouváme o ceně ani deadlinu, ale pouze o rozsahu. Neděláme mega design a architekturu předem, ale postupně během vývoje poznáváme a usměrňujeme zákazníkovo požadavky. Jakmile zákazník ohlásí, že mu to stačí, vývoj může skončit a výsledkem je to, co se postupným vývojem vytvořilo.