Joel on Software - Joels test: 12 stegsmetoden mot bättre kod

Har du hört talas om SEMA? Det är en relativt esoterisk metod för att mäta hur duktigt ditt utvecklingsteam är. Nej, klicka nu inte iväg längs den där länken! Det skulle ta dig minst sex år att sätta dig in i de där prylarna. Jag har istället min egen högst oansvariga, lättvindiga test för att bedöma kvalitén hos en grupp utvecklare. Det bästa med mitt sätt att göra det är att det bara tar 3 minuter.

Det bästa med Joels test är att det är så enkelt att svara ja eller nej på varje fråga. Du behöver inte beräkna siffror på antal-kodrader-per-dag eller genomsnittligt-antal-fel-per-funktion. Ge bara ditt team en poäng för varje fråga som kan besvaras med "ja". Men en varning är på sin plats, du ska kanske inte använda Joels test för att försäkra dig om att ert nya styrprogram för atomreaktorer är helt säkert.

En 12-poängare är förstås perfekt, 11 är acceptabelt, men 10 poäng eller lägre och du har allvarliga problem. Sanningen är att de flesta organisationer som utvecklar mjukvara ligger på 2 eller 3 poäng, och de behöver all hjälp de kan få eftersom företag som Microsoft hela tiden kör på för fullt på 12-poängsnivån.

Detta är förstås inte de enda faktorer som avgör om ni ska lyckas eller gå under. Speciellt om du har ett jättebra utvecklarteam som jobbar på en produkt som ingen vill ha, då spelar det ingen roll om resultatet är av toppkvalitét, det är ändå ingen som är intresserad. Det är å andra sidan fullt möjligt att du har ett hoprafsat gäng mördartyper som inte har en enda poäng men ändå lyckas producera fantastisk programvara som förändrar världen. Men, bortser man från dessa ytterligheter, och ser till att klara dessa 12 frågor på rätt sätt så kan du vara säker på att du har ett disciplinerat team som alltid kan leverera.

1. Använder du källkodshantering?
Jag har använt kommersiella kodhanteringsverktyg och jag har använt CVS, som är fritt, och låt mig bara säga, CVS är bra. Men om du inte har källkodshantering kommer du att knäckas när du försöker få ditt utvecklarteam att samarbeta. Programmerarna kommer då inte att ha någon möjlighet att veta vad andra har gjort. Misstag kan inte heller göras ogjorda på lätt sätt. En annan läcker sak med kodhanteringsverktyg är att själva källkoden finns utcheckad på varje programmerares egen hårddisk - Jag har aldrig hört talas om något projekt som använder källkodshantering som förlorat stora mängder kod i en diskkrash.

2. Kan du bygga produkten i ett enda steg?
Med detta menar jag: hur många steg behövs för att kompilera och bygga en ny version utifrån den aktuella koden? Ett bra team bygger allt med ett enda script som gör en komplett utcheckning, kompilerar om varenda kodrad, bygger exekverbara filer för alla tillgängliga språk och operativsystem med olika #ifdef kombinationer och allt, skapar installationspaket och till slut hela distributionsmedia - CDROM, nerladdningswebsajt eller vad som nu önskas.

Om denna process består av mer än ett ett steg så är den benägen att gå fel. När du närmar dig leverans kommer du att vilja ha mycket korta cykler för att fixa den "sista" buggen, bygga den slutliga versionen av EXE-filen etc. Om det går åt 20 steg för att kompilera koden, köra scriptet som bygger installationspaket mm så kommer du att bli galen och du kommer att begå enkla misstag.

Det var av denna orsak som det sista företaget jag jobbade åt bytte från WISE till InstallShield: vi krävde att installationsprocessen skulle kunna köras automatiskt från ett script nattetid som en schemalagd process i Windows NT och WISE kunde inte köras schemalagt under natten så vi kastade ut det verktyget. (De vänliga människorna hos WISE har senare försäkrat mig om att deras senaste version klarar nattliga byggen.)

3. Bygger du systemet varje dag?
När du använder källkodhantering så kommer förr eller senare någon av programmerarna att av misstag checka in något som inte går att kompilera. Det kan tex vara att de lagt till en ny fil och allt går igenom kompilatorn och fungerar på deras egen utvecklingsmaskin men de glömmer att checka in till filen i det gemensamma kodträdet. Så de går nöjda och glada hem. Men ingen annan kan jobba vidare så de måste också gå hem, dock mindre nöjda.

Att krascha byggprocessen är såpass illa (och såpass vanligt) att det hjälper med dagliga byggen för att försäkra sig om att fel som får processen att krascha inte slipper igenom utan upptäckt. Stora utvecklingsteam kan snabbt upptäcka fel av den här typen genom att tex köra byggprocessen varje eftermiddag, tex under lunchen. Alla kommer då att checka in så många ändringar de kan före lunch. När de kommer tillbaks har bygget gått klart. Om det fungerade, perfekt! Alla checkar då ut den senaste versionen av koden och fortsätter jobba. Om bygget misslyckades fixar ni felen medan alla kan jobba vidare med den fungerande version av koden ni hade innan dagens bygge.

I Excel-teamet hade vi en regel om att den som fick det dagliga bygget att krascha fick övervaka byggprocessen som straff, varje dag tills någon annan kraschade bygget. Detta var ett bra sätt att få folk att låta bli att krascha bygget och att rotera övervakningsjobbet så att alla fick lära sig hur byggprocessen fungerade.

4. Har du en buggdatabas?
Jag bryr mig inte om vad du säger. Om du skriver kod, om än i ett enmansteam, utan en organiserad databas som håller reda på alla kända fel i koden så kommer du att leverera kod med låg kvalitet. Massor av programmerare tror sig kunna hålla bugglistan i sina huvuden. Nonsens, jag kan inte komma ihåg mer än två eller tre buggar i taget, och nästa morgon när det är bråttom att leverera är de som bortblåsta. Du måste absolut ha ett formellt sätt att spåra dina kända fel.

En buggdatabas kan vara komplex eller enkel. En minimal fungerande buggdatabas måste innehålla följande information om varje känt fel:

Om komplexiteten hos buggdatabasen är det enda som hindrar dig från att spåra dina buggar så gör bara en enkel tabell med fem kolumner för dessa viktigaste informationsdetaljer och börja använda den.

5. Fixar du kända fel innan du skriver ny kod?
Den första versionen av Microsoft Word för Windows ansågs vara ett projekt av "dödsmarsch"-karaktär. Det tog evigheter. Det gled iväg. Hela gänget jobbade löjligt mycket, projektet försenades igen, och igen, och igen, och stressen var enorm. När man äntligen lyckades skeppa produkten, flera år för sent, skickade Microsoft hela teamet till Cancun på semester och sen satte man sig ner för att återfinna sig själva.

Man kom fram till att projektledarna hade hållit så hårt på att följa tidplanen att programmerarna helt enkelt hade rusat genom kodfasen medan de skrev usel kod eftersom buggrättningsfasen formellt inte var en del av projektet. Det fanns inte ens ett försök att hålla nere antalet buggar. Det var till och med tvärt om. En historia berättar att en av programmerarna som skrev kod för att beräkna höjden av en textrad helt enkelt skrev "return 12;" och väntade på att buggrapporten om att hans funktion inte alltid gav korrekt svar skulle komma in. Projektplanen var helt enkelt en checklista med funktioner som skulle överföras till att vara buggar. I projektutvärderingen refererar man till detta som "oändliga defektmetoden".

För att rätta till problemet inrättade Microsoft något som man kallar "noll defektmetoden". Många av programmerarna inom företaget skrattade åt det eftersom det lät som ledningen trodde de kunde reducera antalet fel genom ett förbud. "Noll defekter" betydde egentligen att vid varje ögonblick skulle det vara högsta prioritet att eliminera buggar innan ny kod fick skrivas. Här kommer anledningen...

Generellt kan man säga att ju längre man väntar med att fixa ett fel, ju dyrare (i tid och pengar) blir det.

Ett exempel, när du gör ett skrivfel i koden eller råkar få till ett syntaxfel hittar kompilatorn det och det är trivialt att fixa det.

Om du har en bug i din kod som du upptäcker första gången du kör den så kan du enkelt fixa felet eftersom du har allt i färskt minne.

Om du hittar ett fel i kod som du skrev för några dagar sedan så tar det en stund att hitta det, men du kommer snabbt in i det hela när du läser igenom koden och du löser problemet inom rimlig tid.

Men om du hittar en bug i kod som du skrev för flera månader sedan, så har du antagligen glömt massor av detaljer kring det aktuella kodavsnittet och det blir mycket svårare att fixa felet. Vid den här tidpunkten kan du lika gärna sitta och fixa fel i någon annans kod, medan de är på semester på Maldiverna, nu har det övergått till en hel vetenskap att fixa felet: du måste ta det lugnt, metodiskt, vara extremt uppmärksam på alla detaljer och du kan inte säga säkert när det kommer att finnas ett botemedel.

Och om du hittar fel i kod som redan skeppats till kunder kommer du att dra på dig stora kostnader innan det är fixat.

Orsaken till att man ska fixa felen direkt är alltså: Det tar mindre tid på det viset. Det finns ytterligare en orsak, den är relaterad till det faktum att det är lättare att förutsäga hur lång tid det tar att skriva ny kod än att fixa en existerande bug. Om jag t ex bad dig göra en uppskattning av hur lång tid det tar att skriva kod för att sortera en lista så skulle du kunna ge ett ganska bra förslag. Men om jag istället frågade hur lång tid det tar att fixa felet som gör att din kod inte fungerar om Internet Explorer 5.5 är installerat så kan du inte ens gissa, av den enkla anledningen att du inte vet vad som kan orsaka felet. Det kan ta 3 dagar att hitta det eller 2 minuter.

Vad detta betyder är att om du har en plan och massor av fel kvar att fixa, så är planen otillförlitlig. Men om du har rättat alla kända fel, och allt som är kvar är ny kod som väntar på att skrivas, så kommer planen att vara häpnadsväckande exakt.

En annan bra grej med att hålla felsiffran nere på noll är att du kan hävda dig mycket snabbare konkurrensmässigt. En del programmerare refererar till detta som att alltid ha produkten redo för att skeppas. Då kan hindra konkurrenten från att ta dina kunder genom att komma med en ny fräck funktionalitet genom att snabbt implementera just den funktionen och skeppa en ny version genast, utan att vänta på att fixa en massa fel som samlats på hög.

6. Har du en uppdaterad tidplan?
Detta för oss in på ämnet tidplaner. Om din kod överhuvudtaget är viktig för affärerna, så finns det massor av orsaker till varför det är viktigt att de som gör affärerna vet när koden kommer att bli klar. Programmerare är väldigt känsliga när det gäller att göra tidplaner. "Det kommer att vara klart när det är klart!" skriker de åt säljarna.

Tyvärr, funkar det inte riktigt på det viset. Det finns alldeles för många affärsmässiga planeringsbeslut som behöver fattas långt i förväg, innan koden är klar: demonstrationer, mässor, reklam mm. Och enda sättet att klara detta är att ha en tidplan och att se till att den är uppdaterad.

Den andra kritiska detaljen med tidplaner är att de tvingar dig att bestämma vilja funktioner som ska byggas, och därmed tvingas du välja ut de minst viktiga funktionerna och skära bort dem hellre än att drabbas av funktionalitetsförgiftning (också känt som ohämmad funktionalitetstillväxt).

Att hålla en tidplan behöver inte vara svårt. Läs artikeln Painless Software Schedules, som beskriver ett enkelt sätt att göra bra tidplaner.

7. Har du en specifikation?
Att skriva specifikationer är som att använda tandtråd: alla håller med om att det är en bra grej, men ingen gör det.

Jag är inte säker på varför det är så här men antagligen beror det på att de flesta programmerare hatar att skriva dokumentation. Resultatet blir att när ett team som enbart består av programmerare attackerar ett problem, så föredrar de att uttrycka sin lösning i form av kod, hellre än att skriva ett dokument. De dyker hellre rakt ner i kodandet än de sätter sig och skriver en specifikation.

I designfasen kan du rätta till problem som upptäcks genom att redigera ett par textrader. När det väl har skrivits kod så har också kostnaden för att fixa problemet stigit avsevärt, både känslomässigt (folk hatar att kasta bort kod) och i termer av tid, så där finns faktiskt ett motstånd mot att fixa problemet. Mjukvara som inte härstammar från en specifikation tenderar att bli dåligt designad och tidplanen lever ofta sitt eget liv utanför all kontroll. Detta verkar ha varit problemet hos Netscape, där de första fyra versionerna växte till en sådan röra att ledningen dumt nog beslutade att kasta ut all kod och börja om från början. Och de gjorde om samma misstag igen med Mozilla, skapade ett monster som växte okontrollerat och tog flera år att ens få till alfa-stadiet.

Min favoritteori är att detta problem kan lösas genom att avvänja programmerare från sin ovana att skriva genom en intensivkurs i att skriva. En annan lösning är att anställa duktiga projektledare som skriver specifikationer. I varje fall kan man jobba efter regeln "ingen kod utan specifikation".

Lär dig allt om att skriva specifikationer genom att läsa min serie i fyra delar.

8. Har dina programmerare en tyst och lugn arbetsmiljö?
Det finns väldokumenterade produktivitetsökningar som kommer av att ge kunskapsarbetare utrymme, tystnad och avskildhet. Den klassiska ledarskapsboken inom mjukvarubranschen Peopleware dokumenterar dessa fördelar utförligt.

Här kommer problemet. Vi vet alla att kunskapsarbetare jobbar bäst när de är "inne" i jobbet, också känt som att vara "i zonen", där är de totalt koncentrerade på sina arbetsuppgifter och bortkopplade från omvärlden. De tappar tidskoncepten och producerar enormt bra grejer genom absolut fokusering. Det är på detta sätt de får allt sitt produktiva arbete gjort. Författare, programmerare, forskare och till och med basketspelare kan berätta om hur det är att vara "i zonen".

Problemet är att det inte är lätt att ta sig in i zonen. När man försöker mäta så verkar det ta i genomsnitt 15 minuter från arbetets start tills man uppnår maximal produktivitet. Ibland, om du är trött eller redan har gjort mycket kreativt arbete under dagen kan du kanske inte ta dig in i zonen alls och spenderar därför resten av dagen fipplande med olika saker, surfar på webben och spelar Tetris.

Det andra problemet är att det är så lätt att ramla ur zonen. Oväsen, telefonsamtal, avbrott för lunch, krångla 5 minuter för att få kaffe ur automaten, och medarbetare som avbryter -- speciellt medarbetare som avbryter -- alla dessa saker får dig att ramla ur zonen. Om en medarbetare ställer en fråga, vilket ger ett avbrott på 1 minut, och detta får dig att ramla ur zonen på ett tillräckligt bryskt vis så att det tar dig en halvtimme att bli produktiv igen så är din totala produktivitet i stor fara. Om du befinner dig i en stökig miljö av den typ som koffeinstinna moderna företag med öppna kontorslandskap gillar att skapa, med marknadskillar som skriker i telefon alldeles bredvid programmerarna, så kommer din produktivitet att rasa eftersom kunskapsarbetarna avbryts hela tiden och aldrig tar sig in i zonen.

Med programmerare är det extra svårt. Produktivitet beror i det fallet på förmågan att jonglera med massor av finkorniga detaljer i närminnet på samma gång. Vilket litet störande moment som helst kan få alla dessa små detaljer att komma rasande ner i en enda röra. När du återupptar arbetet kan du inte minnas en enda av detaljerna (som tex vilka lokala variabelnamn du använde, eller vilket steg du just höll på att implementera i den nya sökalgoritmen) och du måste leta upp alla sakerna igen, vilket fördröjer arbetet tills du åter fått fram alla detaljerna och kommit upp i varv.

Här är ett enkelt räkneexempel: Låt oss säga (som undersökningarna föreslår) att om en programmerare störs, även bara för en minut så försvinner 15 minuters produktiv tid. I vårt exempel har vi programmerarna Johan och Bertil, i öppna kontorsbås bredvid varandra i en vanlig Dilbert-liknande rutindelad anläggning. Bertil kan inte komma ihåg namnet på Unicode versionen av strcpy()-funktionen. Han kunde slå upp det, vilket tar 30 sekunder, eller fråga Johan, vilket tar 15 sekunder. Eftersom han sitter bredvid Johan så frågar han Johan. Johan avbryts i sitt arbete och förlorar 15 minuter (för att spara 15 sekunder åt Bertil).

Nu flyttar vi de två till separata kontor med väggar och dörrar. När Bertil nu inte kommer ihåg funktionsnamnet så kan han slå upp det, vilket fortfarande tar 30 sekunder, eller så kan han fråga Johan vilket nu tar ca 45 sekunder och inbegriper att han ska resa sig (en inte helt enkel uppgift med hänsyn till den genomsnittlige programmerarens fysik!). Så istället slår han upp det. Nu förlorade Bertil 30 sekunders produktivitet, men sparade 15 minuter åt Johan. Aha!

9. Använder du de bästa verktyg som kan köpas för pengar?
Att skriva kod i ett kompilerat programmeringsspråk är en av de sista grejerna som inte låter sig göras blixtsnabbt på en lågbudgetdator av hemmastandard. Om kompileringen tar mer än ett par sekunder kommer du att spara tid genom att skaffa den senaste snabbaste datormodellen. Om det tar ens 15 sekunder att kompilera kommer programmerarna att bli uttråkade och surfa iväg för att läsa roligheter på webben vilket absorberar dem helt och dödar många produktiva timmar.

Att debugga GUI-kod med bara en bildskärm till datorn är plågsamt, om inte omöjligt. Om du jobbar med utveckling av grafiska gränssnitt kommer dubbla bildskärmar att underlätta mycket.

De flesta programmerare måste förr eller senare redigera bilder för ikoner eller verktygslister, och de flesta har ingen bra bildredigeringsprogramvara tillgänglig. Att försöka med Microsoft Paint är ett skämt, men vad de flesta tvingas göra.

På mitt senaste jobb envisades systemadministratören med att skicka automatiska spammeddelanden om att jag använde mer än... hör och häpna... 220 megabyte hårddiskutrymme på servern. Jag påpekade att med dagens priser på lagringsutrymme så var detta betydligt billigare än kostnaden för det toalettpapper jag gjorde åt med. Att ens ägna 10 minuter för att städa upp min hemkatalog skulle ha varit ett fantastiskt slöseri med produktivitet.

Högt stående utvecklingsteam torterar inte sina programmerare. Till och med små irritationsmoment som orsakas av att man använder underdimensionerade verktyg gör programmerare sura och olyckliga. Och en sur programmerare är en improduktiv programmerare.

Som grädde på moset... Programmerare är lätta att muta genom att ge dem de senaste coolaste prylarna. Vilket är billigare än att betala löner i absoluta toppskiktet!

10. Har du testare?
Om din grupp inte har särskilda testare, åtminstone en för varannan, var tredje programmerare så skeppar du antingen buggiga produkter eller så slösar du pengar genom att högavlönade programmerare gör jobb som kan göras av något billigare testare. Att spara in på testare är så grovt felaktigt ekonomiskt tänkande att jag blir lika förbluffad varje gång jag inser att folk inte förstår problemet.

11. Låter du tilltänkta rekryter skriva kod under anställningsintervjun?
Skulle du anställa en trollkarl utan att fråga om de kan visa några magiska tricks? Troligen inte.

Skulle du anlita en kateringfirma för ditt bröllop utan att provsmaka några av deras rätter? Jag tvivlar. (Om det inte är moster Margot, hon skulle hata dig för evigt om du inte lät henne göra sin speciella tårta med hackad lever.)

Ändå anställs programmerare varje dag på basis av att deras CV ser imponerande ut eller för att intervjuaren tyckte de var trevliga att prata med. Eller så ställs frågor av detaljkaraktär ("vad är skillnaden mellan CreateDialog() och DialogBox()?") som kan besvaras genom att läsa dokumentationen. Du bryr dig inte om de har memorerat tusentals detaljer om programmering, du bryr dig om ifall de kan producera kod. I värsta fall ställer du "Aha!"-frågor: den sorten som är lätta att besvara när du vet svaret men omöjliga att besvara annars.

Snälla, sluta med detta. Gör vad du vill under intervjuer, men se till att kandidaterna får skriva lite kod. (För fler råd, läs Guerrilla Guide to Interviewing .)

12. Testar du användbarhet i korridoren?
Att testa användbarhet i korridoren innebär att du grabbar tag i första bästa person som kommer förbi i korridoren och tvingar dom att testa programmet du jobbar på. Om du gör detta med 5 personer kommer du att hitta 95% av de problem som finns när det gäller användbarhet.

Bra design av användargränssnitt är inte så svårt som du tror, och det är en kritisk faktor som påverksar om kunderna kommer att älska och köpa din produkt. Du kan gärna läsa min gratisbok om användargränssnittsdesign på webben, det är en introduktion för programmerare.

Men det viktigaste är att om du visar ditt program för en handfull människor (5-6 personer räcker) så kommer du att upptäcka de största problemen snabbt. Läs Jakob Nielsens artikel som förklarar varför. Även om du saknar kunskap om användargränssnittsdesign så kommer ditt slutresultat att bli mycket, mycket bättre om du tvingar dig till att börja testa användbarheten i korridoren.