Cargo Cult Software Engineering

I South Seas er det en cargo kult av mennesker. Under krigen så de fly med mange gode materialer, og de vil at det samme skal skje nå. Så de har arrangert for å lage ting som rullebaner, å sette branner langs sidene av rullebanene, å lage en trehytte for en mann å sitte i, med to trebiter på hodet for hodetelefoner og barer av bambus som stikker ut som antenner-han er kontrolleren-og de venter på at flyene skal lande. De gjør alt riktig. Skjemaet er perfekt. Det ser ut akkurat slik det så ut før. Men det virker ikke. Ingen fly lander. Så jeg kaller disse tingene cargo cult science, fordi de følger alle de tilsynelatende forskriftene og former for vitenskapelig undersøkelse, men de mangler noe viktig, fordi flyene ikke lander.
– Richard Feynman

jeg finner det nyttig å trekke en kontrast mellom to ulike organisasjonsutviklingsstiler:” prosessorientert “og” forpliktelsesorientert ” utvikling. Prosessorientert utvikling oppnår sin effektivitet gjennom dyktig planlegging, bruk av nøye definerte prosesser, effektiv bruk av tilgjengelig tid og dyktig anvendelse av software engineering beste praksis. Denne utviklingsstilen lykkes fordi organisasjonen som bruker den, blir stadig bedre. Selv om de tidlige forsøkene er ineffektive, betyr jevn oppmerksomhet på prosessen at hvert påfølgende forsøk vil fungere bedre enn det forrige forsøket.

Forpliktelsesorientert utvikling går under flere navn, inkludert “heltorientert utvikling” og “individuell empowerment.”Engasjementsorienterte organisasjoner er preget av å ansette de beste mulige menneskene, be dem om total forpliktelse til sine prosjekter, gi dem nesten fullstendig autonomi, motivere dem i ekstrem grad, og deretter se at de jobber 60, 80 eller 100 timer i uken til prosjektet er ferdig. Engasjement-orientert utvikling henter sin styrke fra sin enorme motiverende evne-studie etter studie har funnet ut at individuell motivasjon er langt den største enkelt bidragsyter til produktivitet. Utviklere gjør frivillige, personlige forpliktelser til prosjektene de jobber med, og de går ofte til ekstraordinære lengder for å få prosjektene til å lykkes.

Organisatoriske Imposters

når den brukes knowledgeably, kan enten utvikling stil produsere høy kvalitet programvare økonomisk og raskt. Men begge utviklingsstiler har patologiske lookalikes som ikke fungerer nesten like bra, og det kan være vanskelig å skille fra de ekte artiklene.

prosess-imposter-organisasjonen baserer sin praksis på en slavisk hengivenhet til prosess for prosessens skyld. Disse organisasjonene ser på prosessorienterte organisasjoner som NASAS Software Engineering Laboratory og IBMS tidligere Federal Systems Division. De observerer at disse organisasjonene genererer mange dokumenter og holder hyppige møter. De konkluderer med at hvis de genererer et tilsvarende antall dokumenter og holder et tilsvarende antall møter, vil de lykkes på samme måte. Hvis de genererer mer dokumentasjon og holder flere møter, vil de bli enda mer vellykkede! Men de forstår ikke at dokumentasjonen og møtene ikke er ansvarlige for suksessen; de er bivirkningene av noen få spesifikke effektive prosesser. Vi kaller disse organisasjonene byråkratiske fordi de setter form av programvareprosesser over stoffet. Deres misbruk av prosessen er demotiverende, noe som gjør vondt produktivitet. Og de er ikke veldig hyggelig å jobbe for.

engasjement-imposter organisasjonen fokuserer primært på å motivere folk til å jobbe lange timer. Disse organisasjonene ser på vellykkede selskaper Som Microsoft; observere at de genererer svært lite dokumentasjon; tilby aksjeopsjoner til sine ansatte; og så kreve dem til å jobbe fjell av overtid. De konkluderer med at hvis de også minimerer dokumentasjon, tilbyr aksjeopsjoner og krever omfattende overtid, vil de lykkes. Jo mindre dokumentasjon og mer overtid, jo bedre! Men disse organisasjonene savner Det Faktum At Microsoft og andre vellykkede engasjementsorienterte selskaper ikke krever overtid. De ansetter folk som elsker å lage programvare. De team disse menneskene med andre mennesker som elsker å lage programvare like mye som de gjør. De gir overdådig organisatorisk støtte og belønninger for å lage programvare. Og så slår de dem løs. Det naturlige resultatet er at programvareutviklere og ledere velger å jobbe lange timer frivillig. Imposter organisasjoner forvirre effekten (lange timer) med årsaken (høy motivasjon). Vi kaller bedragerorganisasjonene sweatshops fordi de legger vekt på å jobbe hardt i stedet for å jobbe smart, og de pleier å være kaotiske og ineffektive. De er heller ikke veldig hyggelige å jobbe for.

Cargo Cult Software Engineering

ved første øyekast ser disse to typer bedragerorganisasjoner ut til å være nøyaktige motsetninger. Den ene er utrolig byråkratisk, og den andre er utrolig kaotisk. Men en viktig likhet er faktisk viktigere enn deres overfladiske forskjeller. Verken er svært effektiv, og årsaken er at verken forstår hva som virkelig gjør sine prosjekter lykkes eller mislykkes. De går gjennom bevegelsene til å se ut som effektive organisasjoner som er stilistisk like. Men uten noen reell forståelse av hvorfor praksis arbeid, de er egentlig bare stikker biter av bambus i ørene og håper deres prosjekter vil lande trygt. Mange av prosjektene deres ender opp med å krasje fordi disse bare er to forskjellige varianter av cargo cult software engineering, som ligner på deres mangel på forståelse av hva som gjør programvareprosjekter arbeid.

Cargo cult software engineering er lett å identifisere. Cargo cult – programvareingeniører rettferdiggjør deres praksis ved å si: “Vi har alltid gjort det på denne måten tidligere, “eller” våre selskapsstandarder krever at vi gjør det på denne måten”—selv når disse måtene ikke gir mening. De nekter å anerkjenne avvikene som er involvert i enten prosessorientert eller forpliktelsesorientert utvikling. Begge har styrker og svakheter. Når de presenteres med mer effektive, nye praksiser, foretrekker cargo cult-programvareingeniører å bo i sine trehytter med kjente, komfortable og-ikke-nødvendigvis-effektive arbeidsvaner. “Å gjøre det samme igjen og igjen og forvente forskjellige resultater er et tegn på galskap,” sier det gamle ordtaket. Det er også et tegn på cargo cult software engineering.

Den Virkelige Debatten

i dette bladet og i mange andre publikasjoner bruker vi vår tid på å diskutere om prosessen er god eller individuell empowerment (med andre ord engasjementsorientert utvikling) kan være bedre. Dette er en falsk dikotomi. Prosessen er god, og det er også individuell empowerment. De to kan eksistere side om side. Prosessorienterte organisasjoner kan be om en ekstrem forpliktelse på bestemte prosjekter. Engasjement-orienterte organisasjoner kan bruke programvare engineering praksis dyktig.

forskjellen mellom disse to tilnærmingene kommer virkelig ned til forskjeller i stil og personlighet. Jeg har jobbet med flere prosjekter av hver stil, og har likt forskjellige ting om hver stil. Noen utviklere liker å jobbe metodisk på en 8 til 5 tidsplan, noe som er mer vanlig i prosessorienterte selskaper. Andre utviklere liker fokuset og spenningen som følger med å gjøre en 24×7 forpliktelse til et prosjekt. Forpliktelsesorienterte prosjekter er i gjennomsnitt mer spennende, men et prosessorientert prosjekt kan være like spennende når det har et veldefinert og inspirerende oppdrag. Prosessorienterte organisasjoner ser ut til å degenerere til deres patalogiske lookalikes sjeldnere enn forpliktelsesorienterte organisasjoner gjør, men begge stilene kan fungere godt hvis det er dyktig planlagt og utført.

det faktum at både prosessorienterte og forpliktelsesorienterte prosjekter har patologiske lookalikes har muddied debatten. Noen prosjekter utført i hver stil lykkes, og noen mislykkes. Som gjør at en prosess talsmann å peke på prosessen suksess og engasjement feil og hevder at prosessen er nøkkelen til suksess. Det gjør at engasjementet talsmann for å gjøre det samme.

problemet som har falt av veikanten mens vi har diskutert prosess vs forpliktelse, er så åpenbar at Det, som Edgar Allen Poe ‘ s purloined brev, kan det ganske enkelt ha vært så åpenbart at vi har oversett det. Vi bør ikke diskutere prosess vs. engasjement; vi bør diskutere kompetanse vs. inkompetanse. Den virkelige forskjellen er ikke hvilken stil som er valgt, men hva utdanning, opplæring og forståelse er brakt å bære på prosjektet. I stedet for å diskutere prosess vs. forpliktelse, bør vi se etter måter å øke gjennomsnittlig nivå på utvikler og lederkompetanse. Det vil forbedre sjansene for suksess uansett hvilken utviklingsstil vi velger.