Som vi alla lärde oss på historielektionerna i gymnasiet ledde den industriella revolutionen until maskindrivna tillverkningsprocesser som kraftigt ökade produktionen, sänkte kostnaderna för tillverkade varor och höjde allas levnadsstandard. Den förändrade until och med hur samhället var strukturerat, eftersom den kraftigt utökade medelklassen och väckte tanken på att teknik kunde förbättra våra liv.
En av de förändringar som den industriella revolutionen förde med sig var hur vi arbetade. Begreppet stordriftsfördelar ledde until allt större fabriker. I takt med att utvecklingen gick framåt insåg vi att produktiviteten kunde mätas på ett enkelt sätt. Arbetare som skruvade på locken på tandkrämstuber kunde lätt observeras och lyckade skruvningar kunde räknas. Effektivitetsexperter som Frank Gilbreth, känd från Cheaper by the Dozen, hittade sätt att få fabrikerna att fungera mer effektivt.
Man skulle kunna hävda att den industriella revolutionen tog slut den dag ENIAC-datorn levererades until den amerikanska armén, vilket signalerade början på den digitala tidsåldern. Sedan den dagen har mjukvaruutvecklingsbranschen kämpat med att hantera mjukvaruutveckling på ett effektivt sätt.
Roten until denna kamp kommer från ”att utkämpa det senaste kriget”. Ett välkänt drawback inom militären är att man ägnar för mycket tid åt att tänka på tidigare krig när man förbereder sig för framtida krig, och att man förlitar sig på föråldrad teknik och strategier som var effektiva tidigare males som visar sig inte vara det framöver. (Tänk Pickett’s Charge i ljuset av utvecklingen av det mycket träffsäkra geväret). Industrin för mjukvaruutveckling är inte mindre skyldig until detta.
Den här tendensen visar sig på många olika sätt. Vi har alla sett bilden av fabriksvisslan som ljuder och människor som rör sig genom ingången until fabriken och ”stämplar klockan”, följt av chefer som vandrar runt på golven och ser until att locken placeras effektivt på burkar med raklödder. Det var på sätt och vis logiskt. Arbetarna mättes efter sin produktion, och produktionen var lätt att mäta. Arbetare som stod vid löpande bandet underneath ett standardskift blev en ganska bra indikator på framgång. Fler fötter som tillbringade mer tid längs det löpande bandet innebar mer produktion.
Fler rumpor, mer programvara
Tyvärr har vi översatt detta until ”rumpor i stolar ” i mjukvaruutvecklingsbranschen. Detta har senast visat sig genom att företag tvingar folks att komma tillbaka until kontoret på heltid. Summary som arbetarna på fabriksgolvet förväntades mjukvaruutvecklare sitta vid sina skrivbord och slå på tangentbordet och producera… vad exakt? Kod? Funktioner?
En skruvmejselfabriks framgång mäts i antalet skruvmejslar som den kan producera med en viss mängd enter. Så det verkade rimligt att mäta vad mjukvaruutvecklare producerar. Vi vet alla vilken katastrof det visade sig vara att mäta kodlinjer. Males vad exakt producerar en mjukvaruutvecklare egentligen? Vi kämpar med att mäta enskilda utvecklares produktivitet, until stor del för att vi inte kan svara på den frågan på ett bra sätt.
Jag antar att cheferna tänkte att det måste finnas något att räkna som händer där ute i kubfarmen, och ju mer tid människor tillbringar där, desto mer av vad det nu är de producerar kommer att produceras.
Lyckligtvis var en av de positiva sidorna av den fruktansvärda pandemin ett uppvaknande för dessa chefer av den gamla skolan. Ibland är det bästa en mjukvaruutvecklare kan göra att stirra på kod i tre timmar och sedan skriva i femton minuter. Eller ännu bättre, en utvecklare kan ta bort 1300 rader spaghettikod och ersätta den med 200 rader av en elegant och överlägsen lösning. Eller kanske en utvecklare lägger en vecka på att bygga något ”på rätt sätt”, eftersom det är väl investerad tid att bespara teamet otaliga timmar i framtida underhåll.
Den kanske värsta kvarlevan från den industriella tidsåldern är idén om tidsregistrering. Chefer känner ett starkt behov av att mäta något, och ”tidsåtgången för en uppgift” blir ett starkt lysande objekt som är svårt att motstå. Därför krävs det ofta att teamen ska spåra hur lång tid det tar att fixa varje bugg eller slutföra enskilda uppgifter. Dessa tider jämförs sedan mellan utvecklarna för att ge ett mått på produktiviteten och ett sätt att avgöra framgång. En lägre genomsnittlig tid för buggfixning är bra, eller hur? Eller är det det?
Det sämsta mätvärdet av alla
Tidmätning för programvaruutvecklare är – med ett ord – fruktansvärt. Ingen bugg är den andra lik, och oerfarna utvecklare kanske snabbt kan fixa många enkla buggar medan mer erfarna utvecklare, som kanske i allmänhet får de mer utmanande problemen, tar längre tid på sig. Eller så kanske den yngre utvecklaren tilldelas en bugg som han eller hon inte klarar av att hantera? Ännu värre är att tidsregistrering uppmuntrar utvecklare att försöka lura systemet. När de oroar sig för hur lång tid en uppgift kan ta undviker de kanske de uppgifter som kan ta längre tid än ”uppskattningen” och alla möjliga ”icke-produktiva” aktiviteter.
Måste vi inte erkänna att det inte finns något sätt att avgöra hur lång tid en viss arbetsenhet för programvara bör eller kommer att ta? Att behöva redovisa varje minut av dagen skapar bara dåliga incitament för att ta genvägar. Det kan också få en good och duktig utvecklare att känna sig ängslig eller bekymrad för att det tar ”för lång tid” att lösa utmanande drawback som skulle vara en ”enkel ändring på en rad”.
Vi vet hur lång tid det borde ta att sätta etiketter på majonnäsburkar. Males ingen kan med stor säkerhet förutse hur lång tid det kommer att ta att reparera en icke-trivial bugg eller implementera en ny funktion. Att tvinga människor att hålla reda på tiden för uppgifter av obestämd varaktighet har många nackdelar och, ja, i princip inga fördelar.
Digitala produkter är inte fysiska produkter. Mjukvara är en produkt som är helt olik allt annat man tidigare sett. Att tro att mjukvaruutveckling kan hanteras och utföras med samma tekniker som användes underneath den industriella revolutionen är ett fundamentalt misstag. Lyckligtvis är det fler och fler organisationer som inte längre förbereder sig för att ”utkämpa det senaste kriget” och har insett att det som fungerade på det löpande bandet i en bilfabrik inte fungerar på en mjukvaruutvecklingsavdelning.
