Cargo Cult Software Engineering
in de zuidelijke zeeën is er een cargo cult van mensen. Tijdens de oorlog zagen ze vliegtuigen met veel goede materialen, en ze willen dat hetzelfde nu gebeurt. Dus ze hebben geregeld om dingen te maken zoals Start-en landingsbanen, om vuur te maken langs de zijkanten van de start—en landingsbanen, om een houten hut te maken voor een man om in te zitten, met twee houten stukken op zijn hoofd voor koptelefoons en staven van bamboe die uitsteken als antennes—hij is de controller-en ze wachten tot de vliegtuigen landen. Ze doen alles goed. De vorm is perfect. Het ziet er precies zo uit als vroeger. Maar het werkt niet. Geen vliegtuigen landen. Ik noem deze dingen vrachtcultuurwetenschap, omdat ze alle schijnbare voorschriften en vormen van wetenschappelijk onderzoek volgen, maar ze missen iets essentieels, omdat de vliegtuigen niet landen.
– Richard Feynman
ik vind het nuttig om een contrast te tekenen tussen twee verschillende organisatorische ontwikkelingsstijlen: “proces-georiënteerde” en “commitment-oriented” ontwikkeling. Procesgerichte ontwikkeling bereikt zijn effectiviteit door vakkundige planning, gebruik van zorgvuldig gedefinieerde processen, efficiënt gebruik van beschikbare tijd en bekwame toepassing van software engineering best practices. Deze stijl van ontwikkeling slaagt omdat de organisatie die het gebruikt voortdurend verbetert. Zelfs als de eerste pogingen ineffectief zijn, betekent constante aandacht voor het proces dat elke opeenvolgende poging beter zal werken dan de vorige poging.
Commitment-oriented development heeft verschillende namen, waaronder ” hero-oriented development “en” individual empowerment.”Commitment-oriented organisaties worden gekenmerkt door het inhuren van de best mogelijke mensen, hen vragen om totale betrokkenheid bij hun projecten, empowerment hen met bijna volledige autonomie, motiveren tot een extreme mate, en dan zien dat ze werken 60, 80, of 100 uur per week tot het project is voltooid. Commitment-oriented development ontleent zijn kracht aan zijn enorme motivatie vermogen-studie na studie heeft aangetoond dat individuele motivatie is veruit de grootste individuele bijdrage aan de productiviteit. Ontwikkelaars maken vrijwillige, persoonlijke verplichtingen aan de projecten waar ze aan werken, en ze doen vaak buitengewoon veel moeite om hun projecten te laten slagen.
organisationele bedriegers
wanneer ze met kennis van zaken worden gebruikt, kunnen beide ontwikkelingsstijlen Economisch en snel hoogwaardige software produceren. Maar beide ontwikkelingsstijlen hebben pathologische lookalikes die lang niet zo goed werken, en dat kan moeilijk te onderscheiden zijn van de echte artikelen.
de organisatie van proces-bedriegers baseert haar praktijken op een slaafse toewijding aan proces omwille van proces. Deze organisaties kijken naar procesgerichte organisaties zoals NASA ‘s Software Engineering Laboratory en IBM’ s voormalige Federal Systems Division. Ze merken op dat deze organisaties veel documenten genereren en regelmatig vergaderen. Zij komen tot de conclusie dat, indien zij een gelijkwaardig aantal documenten genereren en een vergelijkbaar aantal vergaderingen houden, zij eveneens succesvol zullen zijn. Als ze meer documentatie genereren en meer vergaderingen houden, zullen ze nog succesvoller zijn! Maar ze begrijpen niet dat de documentatie en de vergaderingen niet verantwoordelijk zijn voor het succes; ze zijn de bijwerkingen van een paar specifieke effectieve processen. We noemen deze organisaties bureaucratisch omdat ze de vorm van softwareprocessen boven de inhoud stellen. Hun misbruik van proces is demotiverend, wat de productiviteit schaadt. En ze zijn niet leuk om voor te werken.
de organisatie die zich inzet om mensen te motiveren om lange uren te werken, richt zich in de eerste plaats op het motiveren van mensen om lange uren te werken. Deze organisaties kijken naar succesvolle bedrijven zoals Microsoft; merken op dat ze heel weinig documentatie genereren; bieden aandelenopties aan hun werknemers; en dan moeten ze bergen overuren maken. Zij concluderen dat als ook zij documentatie minimaliseren, aandelenopties aanbieden en uitgebreide overuren vereisen, zij succesvol zullen zijn. Hoe minder documentatie en hoe meer overwerk, hoe beter! Maar deze organisaties missen het feit dat Microsoft en andere succesvolle commitment-georiënteerde bedrijven geen overuren nodig hebben. Ze huren mensen in die graag software maken. Ze werken deze mensen samen met andere mensen die net zo graag software maken als zij. Ze bieden royale organisatorische ondersteuning en beloningen voor het maken van software. En dan laten ze ze gaan. Het natuurlijke resultaat is dat softwareontwikkelaars en managers kiezen om lange uren vrijwillig te werken. Bedriegers-organisaties verwarren het effect (lange uren) met de oorzaak (hoge motivatie). We noemen de bedriegers organisaties sweatshops omdat ze benadrukken hard werken in plaats van slim te werken, en ze hebben de neiging om chaotisch en ineffectief te zijn. Ze zijn ook niet leuk om voor te werken.
Cargo Cult Software Engineering
op het eerste gezicht lijken deze twee soorten bedrieglijke organisaties precies tegenover elkaar te staan. Het ene is ongelooflijk bureaucratisch en het andere is ongelooflijk chaotisch. Maar één belangrijke overeenkomst is belangrijker dan hun oppervlakkige verschillen. Geen van beide is zeer effectief, en de reden is dat geen van beide begrijpt wat zijn projecten echt succesvol of mislukt. Ze gaan door de bewegingen van het kijken als effectieve organisaties die stilistisch vergelijkbaar zijn. Maar zonder echt te begrijpen waarom de praktijken werken, steken ze in wezen stukjes bamboe in hun oren en hopen dat hun projecten veilig zullen landen. Veel van hun projecten uiteindelijk crashen, omdat dit slechts twee verschillende variëteiten van cargo cult software engineering, vergelijkbaar in hun gebrek aan begrip van wat maakt software projecten werken.
Cargo cult Software engineering is eenvoudig te identificeren. Cargo cult software engineers rechtvaardigen hun praktijken door te zeggen:” We hebben het altijd op deze manier gedaan in het verleden, “of”onze bedrijfsnormen vereisen dat we het op deze manier doen” —zelfs als die manieren geen zin hebben. Zij weigeren de afwegingen te erkennen die betrokken zijn bij proces-of commitment-georiënteerde ontwikkeling. Beide hebben sterke en zwakke punten. Wanneer gepresenteerd met meer effectieve, nieuwe praktijken, cargo cult software engineers de voorkeur aan verblijven in hun houten hutten van vertrouwde, comfortabele en-niet-noodzakelijkerwijs-effectieve werkgewoonten. “Steeds weer hetzelfde doen en verschillende resultaten verwachten is een teken van waanzin”, zegt het oude gezegde. Het is ook een teken van cargo cult software engineering.
het echte debat
in dit tijdschrift en in vele andere publicaties besteden we onze tijd aan het bespreken of proces goed is of individuele empowerment (met andere woorden, commitment-oriented development) beter zou kunnen zijn. Dit is een valse tweedeling. Proces is goed, evenals individuele empowerment. De twee kunnen naast elkaar bestaan. Procesgerichte organisaties kunnen vragen om een extreme inzet voor specifieke projecten. Commitment-georiënteerde organisaties kunnen gebruik maken van software engineering praktijken vakkundig.
het verschil tussen deze twee benaderingen komt eigenlijk neer op verschillen in stijl en persoonlijkheid. Ik heb gewerkt aan verschillende projecten van elke stijl, en hebben graag verschillende dingen over elke stijl. Sommige ontwikkelaars genieten van methodisch werken op een 8 tot 5 schema, wat vaker voorkomt in procesgerichte bedrijven. Andere ontwikkelaars genieten van de focus en opwinding die wordt geleverd met het maken van een 24×7 commitment aan een project. Commitment-georiënteerde projecten zijn gemiddeld spannender, maar een procesgericht project kan net zo spannend zijn als het een goed gedefinieerde en inspirerende missie heeft. Proces-georiënteerde organisaties lijken minder vaak te ontaarden in hun pathalogische lookalikes dan commitment-georiënteerde organisaties doen, maar beide stijl kan goed werken als het vakkundig is gepland en uitgevoerd.
het feit dat zowel procesgeoriënteerde als commitmentgeoriënteerde projecten pathologische lookalikes hebben, heeft het debat vertroebeld. Sommige projecten die in elke stijl worden uitgevoerd, slagen en sommige mislukken. Dat stelt een process advocate in staat om te wijzen op het succes van het proces en commitment mislukkingen en beweren dat proces is de sleutel tot succes. Het laat de commitment advocate om hetzelfde te doen.
de kwestie die aan de kant is gevallen terwijl we debatteren over proces vs.engagement is zo schaamteloos dat, net als de gestolen brief van Edgar Allen Poe, het gewoon zo voor de hand ligt dat we het over het hoofd hebben gezien. We moeten niet debatteren over proces Versus betrokkenheid; we moeten debatteren over competentie Versus incompetentie. Het echte verschil is niet welke stijl wordt gekozen, maar wat Onderwijs, opleiding en begrip wordt gebracht op het project. In plaats van te debatteren over proces Versus engagement, zouden we moeten zoeken naar manieren om het gemiddelde niveau van ontwikkelaar en manager competentie te verhogen. Dat zal onze kansen op succes verbeteren, ongeacht welke ontwikkelingsstijl we kiezen.
