Cargo Cult Software Engineering

v jižních mořích je nákladní kult lidí. Během války viděli letadla se spoustou dobrých materiálů a chtějí, aby se to samé stalo i nyní. Takže jsou uspořádány, aby se věci, jako je přistávací dráhy, aby požáry po stranách dráhy, aby se dřevěné chatrče pro muže sedět v, s dva dřevěné kusy na hlavu pro sluchátka a tyče z bambusu trčí jako antény—je to regulátor—a čekat na letadla na zemi. Dělají všechno správně. Forma je perfektní. Vypadá to přesně tak, jak to vypadalo předtím. Ale nefunguje to. Žádná letadla nepřistávají. Takže já tyto věci cargo cult science, protože se řídit všechny zjevné přikázání a formy vědeckého zkoumání, ale chybí jim něco podstatného, protože letadla nepřistanou.
– Richard Feynman

považuji za užitečné nakreslit kontrast mezi dvěma různými styly organizačního rozvoje:” procesně orientovaným “a” závazkem orientovaným ” vývojem. Procesně orientovaný vývoj dosahuje své efektivity prostřednictvím zručného plánování, využití pečlivě definovaných procesů, efektivního využití dostupného času a dovedné aplikace osvědčených postupů softwarového inženýrství. Tento styl vývoje uspěje, protože organizace, která jej používá, se neustále zlepšuje. I když jsou jeho rané pokusy neúčinné, stálá pozornost procesu znamená, že každý následující pokus bude fungovat lépe než předchozí pokus.

vývoj zaměřený na závazky má několik jmen, včetně ” hero-oriented development “a” individual empowerment”.”Závazek orientované organizace, se vyznačují tím, že najme nejlepší možné lidi, ptát se jich na totální nasazení na jejich projekty, dávajíce jim s téměř úplné samostatnosti, motivovat je k extrémní míře, a pak když vidí, že jejich práce 60, 80, nebo 100 hodin týdně, dokud je projekt dokončen. Závazek-orientovaný vývoj odvozuje svou účinnost od jeho obrovský motivační schopnosti—studie poté, co studie zjistila, že jednotlivé motivace je zdaleka největším přispěvatelem k růstu produktivity. Vývojáři se dobrovolně, osobní závazky k projektům, na kterých pracují, a často jdou do mimořádných délek, aby jejich projekty uspěly.

organizační podvodníci

při použití vědomě může buď vývojový styl produkovat vysoce kvalitní software ekonomicky a rychle. Ale oba vývojové styly mají patologické dvojníky, které nefungují téměř stejně dobře, a to může být obtížné odlišit od skutečných článků.

organizace procesních podvodníků zakládá své praktiky na otrocké oddanosti procesu pro proces. Tyto organizace se zaměřují na procesně orientované organizace, jako je laboratoř softwarového inženýrství NASA a Bývalá divize federálních systémů IBM. Pozorují, že tyto organizace generují spoustu dokumentů a pořádají časté schůzky. Usuzují, že pokud se budou generovat stejné množství dokumentů a podržte srovnatelný počet schůzek budou podobně úspěšné. Pokud vygenerují více dokumentace a uspořádají více schůzek, budou ještě úspěšnější! Nechápou však, že dokumentace a schůzky nejsou zodpovědné za úspěch; jsou to vedlejší účinky několika specifických účinných procesů. Tyto organizace nazýváme byrokratickými, protože dávají formu softwarových procesů nad podstatu. Jejich zneužití procesu je demotivující, což škodí produktivitě. A není pro ně moc příjemné pracovat.

organizace pro podvodníky se zaměřuje především na motivaci lidí k dlouhé pracovní době. Tyto organizace se dívají na úspěšné společnosti, jako je Microsoft; všimněte si, že generují velmi málo dokumentace; svým zaměstnancům nabízejí akciové opce; a pak je třeba, aby pracovali přesčas. Došli k závěru, že pokud i oni minimalizují dokumentaci, nabízejí akciové opce a vyžadují rozsáhlé přesčasy, budou úspěšní. Čím méně dokumentace a více přesčasů, tím lépe! Těmto organizacím však chybí skutečnost, že Microsoft a další úspěšné společnosti zaměřené na závazky nevyžadují přesčasy. Najímají lidi, kteří rádi vytvářejí software. Spojují tyto lidi s ostatními lidmi, kteří rádi vytvářejí software stejně jako oni. Poskytují bohatou organizační podporu a odměny za vytváření softwaru. A pak je uvolní. Přirozeným výsledkem je, že vývojáři a manažeři softwaru se rozhodnou dobrovolně pracovat dlouhé hodiny. Podvodné organizace zaměňují účinek (dlouhé hodiny) s příčinou (vysoká motivace). Podvodným organizacím říkáme manufaktury, protože kladou důraz spíše na tvrdou práci než na inteligentní práci, a mají tendenci být chaotické a neúčinné. Ani pro ně není moc příjemné pracovat.

Cargo Cult Softwarové inženýrství

na první pohled se tyto dva druhy podvodných organizací zdají být přesnými protiklady. Jeden je neuvěřitelně byrokratický a druhý neuvěřitelně chaotický. Jedna klíčová podobnost je však ve skutečnosti důležitější než jejich povrchní rozdíly. Ani jeden není velmi efektivní a důvodem je to, že ani jeden nechápe, co skutečně dělá jeho projekty úspěšné nebo neúspěšné. Procházejí pohyby vypadat jako efektivní organizace, které jsou stylisticky podobné. Ale bez skutečného pochopení toho, proč tyto postupy fungují, v podstatě jen strkají kousky bambusu do uší a doufají, že jejich projekty bezpečně přistanou. Mnoho z jejich projektů skončí zhroucením, protože se jedná pouze o dvě různé odrůdy softwarového inženýrství cargo cult, podobné jejich nedostatečnému pochopení toho, co dělá softwarové projekty práce.

Softwarové inženýrství Cargo cult je snadno identifikovatelné. Softwaroví inženýři Cargo cult ospravedlňují své praktiky slovy: “v minulosti jsme to vždy dělali tímto způsobem” nebo “standardy naší společnosti vyžadují, abychom to udělali tímto způsobem”—i když tyto způsoby nedávají smysl. Odmítají uznat kompromisy zapojené do vývoje orientovaného na proces nebo na závazek. Oba mají silné i slabé stránky. Když jsou softwaroví inženýři cargo cult prezentováni účinnějšími a novými postupy, raději zůstávají ve svých dřevěných chatkách známých, pohodlných a ne nutně efektivních pracovních návyků. “Dělat to samé znovu a znovu a očekávat různé výsledky je známkou šílenství,” říká staré přísloví. Je to také známka softwarového inženýrství cargo cult.

Diskuse

V tomto časopise a v mnoha dalších publikací, trávíme čas debatují, zda proces je dobrý nebo individuální zmocnění (jinými slovy, závazek-orientovaný vývoj) by mohlo být lepší. Toto je falešná dichotomie. Proces je dobrý, a tak je individuální posílení. Ti dva mohou existovat vedle sebe. Procesně orientované organizace mohou požádat o extrémní závazek ke konkrétním projektům. Organizace zaměřené na závazky mohou dovedně používat postupy softwarového inženýrství.

rozdíl mezi těmito dvěma přístupy skutečně spočívá v rozdílech stylu a osobnosti. Pracoval jsem na několika projektech každého stylu, a líbilo se mi různé věci o každém stylu. Někteří vývojáři rádi pracují metodicky na plánu 8 až 5, což je běžnější v procesně orientovaných společnostech. Ostatní vývojáři nyní zaměření a vzrušení, které přichází s tím, že 24×7 závazek k projektu. Projekty zaměřené na závazky jsou v průměru více vzrušující, ale procesně orientovaný projekt může být stejně vzrušující, když má dobře definované a inspirativní poslání. Proces-orientované organizace, zdá se, zvrhnout jejich pathalogical dvojníky méně často než závazek-orientované organizace, ale buď styl může dobře fungovat, pokud je šikovně plánované a popraven.

skutečnost, že jak projekty zaměřené na proces, tak projekty zaměřené na závazky mají patologické pohledy, debatu zamlžila. Některé projekty prováděné v každém stylu uspějí a některé selhávají. To umožňuje obhájci procesu poukázat na úspěch procesu a selhání závazků a tvrdit, že proces je klíčem k úspěchu. To umožňuje závazku obhájce udělat totéž.

problém, který spadl na vedlejší kolej, když jsme diskutovali proces vs. závazek, je tak do očí bijící, že, stejně jako dopis Edgara Allena Poea, to může být prostě tak zřejmé, že jsme to přehlédli. Neměli bychom diskutovat o procesu vs. závazku; měli bychom diskutovat o kompetenci vs. nekompetentnosti. Skutečný rozdíl není, který styl je vybrán, ale jaké vzdělání, výcvik, a porozumění je přineseno na projektu. Spíše než debatovat o procesu vs. závazku bychom měli hledat způsoby, jak zvýšit průměrnou úroveň kompetencí vývojářů a manažerů. To zlepší naše šance na úspěch bez ohledu na to, jaký styl vývoje zvolíme.