Cargo Cult Software Engineering

i södra havet finns en lastkult av människor. Under kriget såg de flygplan med massor av bra material, och de vill att samma sak ska hända nu. Så de har ordnat att göra saker som landningsbanor, att sätta bränder längs banans sidor, att göra en trähytt för en man att sitta i, med två träbitar på huvudet för hörlurar och bambustänger som sticker ut som antenner—han är styrenheten—och de väntar på att flygplanen ska landa. De gör allt rätt. Formen är perfekt. Det ser ut precis som det såg ut Tidigare. Men det fungerar inte. Inga flygplan landar. Så jag kallar dessa saker cargo cult science, för att de följer alla uppenbara föreskrifter och former av vetenskaplig undersökning, men de saknar något väsentligt, för att planen inte landar.
— Richard Feynman

jag tycker att det är användbart att dra en kontrast mellan två olika organisationsutvecklingsstilar: “processorienterad” och “engagemangsorienterad” utveckling. Processorienterad utveckling uppnår sin effektivitet genom skicklig planering, användning av noggrant definierade processer, effektiv användning av tillgänglig tid och skicklig tillämpning av bästa praxis för programvaruteknik. Denna utvecklingsstil lyckas eftersom organisationen som använder den ständigt förbättras. Även om dess tidiga försök är ineffektiva, innebär stadig uppmärksamhet på processen att varje på varandra följande försök kommer att fungera bättre än det tidigare försöket.

Engagemangsorienterad utveckling går under flera namn inklusive “hjältorienterad utveckling” och “individuell bemyndigande.”Engagemangsorienterade organisationer kännetecknas av att anställa de bästa möjliga människorna, be dem om totalt engagemang för sina projekt, ge dem nästan fullständig autonomi, motivera dem i extrem grad och sedan se att de arbetar 60, 80 eller 100 timmar i veckan tills projektet är klart. Engagemangsorienterad utveckling härleder sin styrka från sin enorma motivationsförmåga-studie efter studie har funnit att individuell motivation är den överlägset största enskilda bidragsgivaren till produktivitet. Utvecklare gör frivilliga, personliga åtaganden till de projekt de arbetar med, och de går ofta till extraordinära ansträngningar för att få sina projekt att lyckas.

organisatoriska bedragare

när de används knowledgeably, antingen utveckling stil kan producera högkvalitativ programvara ekonomiskt och snabbt. Men båda utvecklingsstilarna har patologiska lookalikes som inte fungerar nästan lika bra, och det kan vara svårt att skilja från de äkta artiklarna.

processbedrägeriorganisationen baserar sin praxis på en slavisk hängivenhet för process för processens skull. Dessa organisationer tittar på processorienterade organisationer som NASAs Software Engineering Laboratory och IBMs tidigare Federal Systems Division. De observerar att dessa organisationer genererar massor av dokument och håller frekventa möten. De drar slutsatsen att om de genererar ett motsvarande antal dokument och håller ett jämförbart antal möten kommer de att bli lika framgångsrika. Om de genererar mer dokumentation och håller fler möten blir de ännu mer framgångsrika! Men de förstår inte att dokumentationen och mötena inte är ansvariga för framgången; de är biverkningarna av några specifika effektiva processer. Vi kallar dessa organisationer byråkratiska eftersom de sätter formen av mjukvaruprocesser över ämnet. Deras missbruk av processen är demotiverande, vilket gör ont produktivitet. Och de är inte så roliga att arbeta för.

engagemangsorganisationen fokuserar främst på att motivera människor att arbeta långa timmar. Dessa organisationer tittar på framgångsrika företag som Microsoft; Observera att de genererar väldigt lite dokumentation; erbjuda aktieoptioner till sina anställda; och sedan kräva dem att arbeta berg av övertid. De drar slutsatsen att om de också minimerar dokumentationen, erbjuder aktieoptioner och kräver omfattande övertid, kommer de att lyckas. Ju mindre dokumentation och ju mer Övertid, desto bättre! Men dessa organisationer saknar det faktum att Microsoft och andra framgångsrika engagemangsorienterade företag inte behöver Övertid. De anställer människor som älskar att skapa programvara. De team dessa människor med andra människor som älskar att skapa programvara lika mycket som de gör. De ger påkostade organisatoriskt stöd och belöningar för att skapa programvara. Och sedan vänder de dem loss. Det naturliga resultatet är att programutvecklare och chefer väljer att arbeta långa timmar frivilligt. Imposterorganisationer förvirrar effekten (långa timmar) med orsaken (hög motivation). Vi kallar bedragarorganisationerna sweatshops eftersom de betonar att arbeta hårt snarare än att arbeta smart, och de tenderar att vara kaotiska och ineffektiva. De är inte så roliga att arbeta för heller.

Cargo Cult Software Engineering

vid första anblicken verkar dessa två typer av bedrägeriorganisationer vara exakta motsatser. Den ena är otroligt byråkratisk, och den andra är otroligt kaotisk. Men en viktig likhet är faktiskt viktigare än deras ytliga skillnader. Varken är mycket effektiv, och anledningen är att varken förstår vad som verkligen gör sina projekt lyckas eller misslyckas. De går igenom rörelserna för att se ut som effektiva organisationer som är stilistiskt lika. Men utan någon verklig förståelse för varför metoderna fungerar, sticker de i huvudsak bara bitar av bambu i öronen och hoppas att deras projekt kommer att landa säkert. Många av deras projekt slutar krascha eftersom det bara är två olika sorter av cargo cult software engineering, liknande i deras brist på förståelse för vad som får mjukvaruprojekt att fungera.

Cargo cult software engineering är lätt att identifiera. Cargo cult software engineers rättfärdigar sin praxis genom att säga, “Vi har alltid gjort det på det här sättet tidigare” eller “våra företagsstandarder kräver att vi gör det på det här sättet”—även när dessa sätt inte ger någon mening. De vägrar att erkänna de kompromisser som är involverade i antingen processorienterad eller engagemangsorienterad utveckling. Båda har styrkor och svagheter. När de presenteras med mer effektiva, nya metoder föredrar cargo cult-programvaruingenjörer att stanna i sina trähytter med bekanta, bekväma och inte nödvändigtvis effektiva arbetsvanor. “Att göra samma sak om och om igen och förvänta sig olika resultat är ett tecken på galenskap”, säger Det gamla ordspråket. Det är också ett tecken på cargo cult software engineering.

den verkliga debatten

i den här tidningen och i många andra publikationer spenderar vi vår tid på att diskutera om processen är bra eller individuell empowerment (med andra ord engagemangsorienterad utveckling) kan vara bättre. Detta är en falsk dikotomi. Processen är bra, och så är individuell empowerment. De två kan existera sida vid sida. Processorienterade organisationer kan begära ett extremt engagemang för specifika projekt. Engagemangsorienterade organisationer kan använda programvaruteknik skickligt.

skillnaden mellan dessa två tillvägagångssätt kommer verkligen ner till skillnader i stil och personlighet. Jag har arbetat med flera projekt av varje stil, och har gillat olika saker om varje stil. Vissa utvecklare tycker om att arbeta metodiskt på ett 8 till 5-schema, vilket är vanligare i processorienterade företag. Andra utvecklare njuta av fokus och spänning som kommer med att göra en 24 GHz 7 engagemang för ett projekt. Engagemangsorienterade projekt är i genomsnitt mer spännande, men ett processorienterat projekt kan vara lika spännande när det har ett väldefinierat och inspirerande uppdrag. Processorienterade organisationer verkar degenerera i sina patalogiska lookalikes mindre ofta än engagemangsorienterade organisationer gör, men endera stilen kan fungera bra om den är skickligt planerad och utförd.

det faktum att både processorienterade och engagemangsorienterade projekt har patologiska lookalikes har muddied debatten. Vissa projekt som genomförs i varje stil lyckas, och vissa misslyckas. Det gör det möjligt för en process förespråkare att peka på processen framgång och engagemang misslyckanden och hävdar att processen är nyckeln till framgång. Det gör det möjligt för engagemangsförespråkaren att göra samma sak.

frågan som har fallit vid vägen medan vi har debatterat process vs. engagemang är så blatant att det, som Edgar Allen Poes purloined brev, helt enkelt kan ha varit så uppenbart att vi har förbisett det. Vi bör inte debattera process vs. engagemang; vi bör debattera kompetens vs. inkompetens. Den verkliga skillnaden är inte vilken stil som väljs, men vilken utbildning, utbildning och förståelse som kommer att bära på projektet. I stället för att debattera process vs. engagemang, bör vi leta efter sätt att höja den genomsnittliga nivån på utvecklare och chefskompetens. Det kommer att förbättra våra chanser att lyckas oavsett vilken utvecklingsstil vi väljer.