Joel on Software   Joel om Software

Andre "Joel on Software" artikler på dansk

Andre "Joel on Software" artikler på engelsk

Send en mail til forfatteren (kun på engelsk)

Har du hørt om SEMA? Det er et ret sindrigt system, der bruges til at måle hvor godt et softwareudviklingshold er. Nej, vent! Lad være med at klikke på linket! Det vil tage dig seks år at forstå systemet. Så jeg har fundet på min egen, yderst uansvarlige og sjuskede test til at bedømme kvaliteten af et udviklingshold. Fordelen ved den er, at den tager omkring 3 minutter. Med al den tid du sparer, får du tid til at læse medicin.

Det gode ved Joel-testen er at det er hurtigt og let at svare enten ja eller nej til hvert spørgsmål. Du behøver ikke beregne antal-skrevne-linier-kode-pr-dag eller gennemsnitligt-antal-fejl-pr-infliktionspunkt. Giv dit hold 1 point for hvert "ja", du svarer. Det er bare ærgeligt med Joel-testen, at du faktisk ikke kan bruge den til at afgøre om softwaren på dit atomkraftværk er sikkert eller ej.

12 point er perfekt. 11 kan tolereres, men 10 eller derunder betyder, at man har alvorlige problemer. Realiteten er, at de fleste softwareproducenter har 2 eller 3 point, hvilket vil sige at de har alvorligt brug for hjælp, fordi virksomheder som Microsoft kører med 12 point hele tiden.

Naturligvis er disse ikke de eneste afgørende faktorer. Har du et fremragende udviklingshold til at arbejde på et produkt som ingen vil have, tja, så vil ingen have det. Og ligeledes kan man forestille sig et hold guerillaprogrammører, der ikke holder sig til en eneste regel, og som det alligevel lykkes at producere fantastisk software, som ændrer verden. Men alt andet lige, hvis du har styr på disse 12 regler, har du et disciplineret hold, der konsistent kan levere varen.

1. Bruger I versionsstyring?
Jeg har brugt kommercielle versionsstyringssystemer og jeg har brugt CVS, som er gratis, og lad det være sagt med det samme, CVS er ganske udmærket. Men hvis I ikke bruger versionsstyring, kommer I til at koge over, bare i forsøget på at få programmørerne til at arbejde sammen. I så fald kan de umuligt vide hvad andre har lavet og det er svært at gå tilbage til en tidligere udgave, hvis der opstår fejl. En anden fed ting ved versionsstyring er, at alle programmører checker koden ud på deres egne harddiske - Jeg har aldrig hørt om et projekt, hvor der blev anvendt versionsstyring, hvor større mængder kode er gået tabt.

2. Kan I lave et build i ét skridt?
Med dette mener jeg: hvor mange skridt skal gennemgås for at lave et færdigt build fra den seneste udgave af kildekoden? Gode hold har ét script som checker al koden ud, oversætter den, laver EXE-filer i alle givne versioner, sprog og #ifdef-kombinationer, laver installationspakken samt det endelige medium - layout til CD-ROM, website til download, eller hvad det end måtte være.

Hvis denne proces skal udføres i mere end ét skridt, er den en potentiel fejlkilde. Og jo nærmere deadline kommer, des mere har man brug for en hurtig måde at rette den "seneste" fejl på, lave de endelige EXE-filer etc. Hvis man skal gennem 20 skridt for at oversætte koden, lave installer etc., løber man sur i det og laver dumme fejl.

Alene af denne grund skiftede det sidste firma, jeg arbejdede for, fra WISE til InstallShield - vi krævede at installeren skulle kunne laves fra ét script, automatisk, i løbet af natten, med NT scheduler'en, og det kunne WISE ikke, så vi smed det ud. (De flinke mennesker hos WISE forsikrer mig om, at deres seneste version understøtter dette nu.)

3. Laver I builds dagligt?
Når man bruger versionsstyring, sker det, at en programmør cheker noget kode ind, som ødelægger build'et. Det sker f.eks. hvis man har tilføjet en ny source-fil og alting virker fint på ens maskine, men man glemmer at lægge filen op på serveren. Man låser så sin maskine og går glad og intetanende hjem. Men ingen af de andre kan arbejde, så de går også hjem, knap så glade.

At ødelægge build'et er så ærgeligt (og så udbredt), at det hjælper at lave et build dagligt, for at sikre sig at ingen ødelæggelse går ubemærket hen.
På større hold kan det være en fordel at lave et build for eksempel ved frokosttid. Alle checker så meget ind som muligt før frokost, og når de kommer tilbage, er build'et færdigt. Hvis det virker, er det fint. Alle checker den seneste version af kildekoden ud, og arbejder videre. Hvis der var fejl i buildet, rettes det, men alle kan fortsætte med at arbejde på deres lokale udgave fra før, som virker.

På Excel-holdet havde vi en regel, der sagde, at den, der ødelagde build'et, skulle "straffes" ved at være ansvarlig for at holde øje med builds, indtil en anden ødelagde det. Dette var godt incitament til ikke at ødelægge build'et, og samtidig en god måde at lære alle hvordan buildprocessen forløber.

Læs mere om daglige builds i min artikel, Daily Builds are Your Friend.

4. Har I en database over fejl?
Uanset, hvad man siger —hvis man udvikler kode selv, ene mand, uden en organiseret database, der indeholder alle kendte fejl i koden, så kommer man til at lave kode af lav kvalitet. Mange programmører tror, at de kan huske alle fejlene i hovedet. Vrøvl. Jeg kan ikke huske mere end to eller tre fejl ad gangen, og morgenen efter, eller i hastværket før levering, glemmes de. Man bliver simpelthen nødt til at holde styr på fejlene på en formel måde.

Databaser over fejl kan være komplekse eller simple. En minimal, men brugbar database må og skal indeholde følgende data for hver fejl:

• Komplet beskrivelse af hvordan fejlen kan genskabes
• Forventet opførsel
• Observeret (fejlbehæftet) opførsel
• Hvem der skal tage sig af fejlen
• Om den er blevet rettet eller ej

Hvis kompleksiteten er det eneste der holder dig fra at holde øje med dine fejl, så lav en tabel med 5 kolonner med disse punkter som overskrifter, og brug den.

For mere information om at holde styr på fejl, se Painless Bug Tracking.

5. Retter I fejl før I skriver ny kode?
Den første version af Microsoft Word blev betragtet som en dødssejler. Det tog evigheder. Planen blev hele tiden overskredet. Hele holdet havde fuldstændig latterligt lange arbejdsdage, projektet blev forsinket igen og igen og igen og stressniveauet var utroligt højt. Da de endelig var færdige, flere år forsinket, sendte Microsoft hele holdet på ferie til Cancun i Mexico, og gik selv igang med en alvorlig selvransagelse.

De indså, at projektlederne havde insisteret så meget på at holde sig til "planen", at programmørerne simpelthen måtte skynde sig igennem kodningsfasen, med det resultat at koden blev meget ringe, fordi der ikke var reserveret tid til fejlrettelser i planen. Der blev intet gjort for at holde fejlprocenten nede. Tværimod. Rygtet vil vide, at en programmør, som var ansvarlig for at skrive koden, der skulle beregne højden af en linie tekst, simpelthen skrev "return 12;" og ventede på at fejlrapporteringen skulle sige, at hans funktion ikke altid virkede korrekt. Projektplanen blev simpelthen til en checkliste over features, som én efter én blev lavet om til fejl. Dette blev senere beskrevet som "infinite defects methodology" (uendeligt antal defekter metodologi).

For at løse problemet indførte Microsoft noget de kaldte en "zero defects methodology" (ingen defekter metodologi) i hele virksomheden. Mange af firmaets programmører grinede, fordi det lød som om, ledelsen troede den kunne forbedre fejlprocenten med ren management-sludder. "Ingen defekter" betød rent faktisk at fejlrettelser altid har højere prioritet end at skrive ny kode. Grunden til dette er:

Generelt gælder det, at jo længere man venter med at rette en fejl, desto dyrere (i tid og penge) bliver det at rette den.

Hvis man for eksempel laver en stave- eller syntaksfejl som compileren fanger, er det trivielt at rette.

Hvis man finder en fejl i sin kode, første gang man prøver at køre den, er fejlen hurtigt rettet, fordi al koden ligger frisk i programmørens hukommelse.

Hvis man finder en fejl i noget kode som man skrev for et par dage siden, tager det lidt tid at finde den, men så snart man læser koden, kommer man i tanke om hvordan det hænger sammen, og kan rette fejlen forholdsvist hurtigt.

Men hvis man finder en fejl i noget kode, som man skrev for et par måneder siden, har man formentlig glemt en masse om koden, og så bliver fejlen sværere at rette. På det tidspunkt kan det endda være, at det er en anden programmørs kode man retter i, og den programmør er måske taget på ferie til Costa del Sol, hvilket gør fejlrettelsen til en ren akademisk disciplin: man bliver nødt til langsomt og metodiskt at gennemgå koden, og det er svært at anslå, hvor lang tid det vil tage at rette fejlen.

Og hvis man finder en fejl i noget kode, der allerede er leveret, bliver det rigtig dyrt at rette fejlen.

Det er én grund til at rette fejl med det samme: det tager mindre tid. Der er en anden grund, som hænger sammen med, at det er lettere at forudsige, hvor lang tid det tager at skrive ny kode, end hvor lang tid det tager at rette en fejl. Hvis jeg for eksempel beder dig om at forudsige, hvor lang tid det vil tage at skrive koden til at sortere en liste, vil du kunne give mig et rimeligt estimat. Men hvis jeg spørger dig om, hvor lang tid det vil tage dig at rette den fejl, der gør, at din kode ikke virker, hvis Internet Explorer 5.5 er installeret, kan du end ikke give et gæt, fordi du pr. definition ikke ved, hvad der forårsager fejlen. Det kan tage 3 dage at finde eller det kan tage 2 minutter.

Dette betyder, at hvis du har en plan med en masse fejl, der mangler at blive rettet, så er planen upålidelig. Men hvis du har rettet alle kendte fejl, og det eneste, der mangler, er ny kode, er din plan væsentligt mere korrekt.

En anden fordel ved at holde fejlprocenten på nul er, at man hurtigere kan svare på konkurrenternes tiltag. Nogle programmører betragter dette som at holde produktet klart til levering hele tiden. Hvis din konkurrent introducerer en ny feature, som stjæler dine kunder, kan du hurtigt implementere denne feature og levere uden først at skulle rette et stort antal ophobede fejl.

6. Har I en opdateret tidsplan?
Hvilket bringer os videre til projektplaner. Hvis ens kode er vigtig for firmaet, er der adskillige grunde til, at det er vigtigt at vide, hvornår koden er færdig.
Programmører er utroligt dårlige til at lave projektplaner. "Det er færdigt, når det er færdigt!", råber de ad forretningsfolkene.

Det er desværre bare ikke godt nok. Der er for mange beslutninger med hensyn til planlægningen, som firmaet bliver nødt til at tage længe før, koden kan leveres: demo-udgaver, deltagelse i messer, reklamekampagner etc. Og den eneste måde, det kan lade sig gøre på, er ved at have en projektplan, og holde den løbende opdateret.

Det andet væsentlige punkt ved at have en projektplan er, at den tvinger en til at beslutte, hvilke features man vil lave, og derved tvinger en til at udvælge de mindst vigtige features, og skære dem fra, i stedet for at havne i et anfald af featuritis.

At lave og vedligeholde en projektplan behøver ikke være svært. Læs min artikel Painless Software Schedules, der beskriver en simpel metode til at lave gode projektplaner.

7. Har I en kravspecifikation?
At skrive en specifikation er lidt som at bruge tandtråd: alle er enige om, at det er fornuftigt, men ingen gør det.

Jeg er ikke sikker på, hvorfor det er sådan, men det er sikkert fordi, de fleste programmører hader at skrive dokumenter. Resultatet bliver, at når et hold programmører angriber et problem, foretrækker de at udtrykke deres løsning i kode, snarere end i dokumenter. De vil meget hellere skrive koden med det samme, end skrive en specifikation først.

På designstadiet er det let at løse problemer ved at ændre i et par liniers tekst. Så snart koden er skrevet koster det væsentligt mere at løse et problem, både følelsesmæssigt (fordi folk hader at smide velfungerende kode ud), og i form af tid. Resultatet bliver, at der opstår modvilje til at løse problemerne. Software, der ikke er blevet lavet ud fra en specifikation, ender med et dårligt internt design, og en projektplan, der ikke kan overholdes. Dette synes at have været problemet hos Netscape, hvor de første fire versioner blev så rodede, at ledelsen meget dumt besluttede at smide koden ud og starte forfra. Og så gentog de deres fejl med Mozilla, ved at skabe et monster, som man mistede kontrollen over, og som tog flere år om at nå alpha stadiet.

Min teori er, at dette problem kan løses ved at lære programmører at være mindre modvillige til at skrive, ved at give dem et intensivt skrivekursus. En anden løsning er at ansætte dygtige chefprogrammører, som skriver specifikationen. Uanset hvad, bør man håndhæve reglen, "ingen kode uden kravspecifikation".

Lær alt om at skrive specifikationer ved at læse min serie i 4 dele.

8. Har jeres programmører rolige arbejdsforhold?
Der er veldokumenterede fordele ved at give vidensarbejdere plads og ro. Den klassiske bog om ledelse af softwareprojekter, Peopleware, dokumenterer disse fordele i dybden.

Problemet er som følger. Vi ved alle, at vidensarbejdere arbejder bedst ved at arbejde i et sammenhængende forløb, også kendt som at "komme i zonen", hvor de er fuldt koncentrerede om deres arbejde, og glemmer alt om omgivelserne. De mister fornemmelsen for tid, og producerer fremragende arbejde gennem absolut koncentration. Det er her, de får alt deres produktive arbejde lavet. Forfattere, programmører, videnskabsfolk, ja selv basketballspillere, kan tale med om at være i zonen.

Problemet er, at det ikke er let at komme "i zonen". Hvis man forsøger at måle det, ser det ud som om det tager gennemsnitligt 15 minutter at komme til at arbejde med maksimal produktivitet. Af og til, hvis man er træt eller allerede har lavet en masse kreativt arbejde den dag, kan man bare ikke komme i zonen og man bruger resten af dagen på at vandre rundt, surfe på nettet og spille Tetris.

Det andet problem er, at det er meget let at blive slået ud af zonen. Støj, telefonopkald, frokost og afbrydelser fra kolleger — især afbrydelser fra kolleger — slår dig ud af zonen. Hvis en 1-minutsarbrydelse fra en kollega er nok til at slå en så meget ud af zonen, at det tager en halv time at blive produktiv igen, så er ens produktivitet hele tiden i fare. Hvis man befinder sig i et støjende miljø som det, dotcom-selskaberne elsker at skabe, hvor marketingsfolk råber i telefonen lige ved siden af programørerne, ender man med en ringe produktivitet, fordi vidensarbejderne bliver afbrudt hele tiden og aldrig kan komme i zonen.

Det er specielt svært med programmører. Produktiviteten afhænger af evnen til at jonglere med en masse små detaljer i korttidshukommelsen på én gang. En hvilken som helst form for afbrydelse får det hele til at styrte sammen. Når de genoptager arbejdet, kan de ikke huske detaljerne (som de variabelnavne, de brugte eller hvor de var henne i implementeringen af en algoritme), og så bliver de nødt til igen at finde alle disse detaljer, hvilket sløver dem endnu mere, indtil de igen kommer op i hastighed.

Her er den simple algebra: Lad os sige (som det synes at forholde sig), at hvis vi afbryder en programmør, blot i ét minut, ødelægger vi i virkeligheden 15 minutters produktivitet. Til eksemplet bruger vi to programmører, Jeff og Mutt, der sidder i hver deres lille aflukke — et standard Dilbert-agtigt miljø. Mutt har glemt navnet på Unicode-udgaven af strcpy-funktionen. Han kan slå det op, hvilket tager 30 sekunder, eller han kan spørge Jeff, hvilket tager 15 sekunder. Siden han sidder lige ved siden af Jeff, spørger han Jeff. Jeff bliver distraheret og mister 15 minutters produktivitet (for at spare Mutt 15 sekunder).

Lad os i stedet flytte dem i hver sit separate kontor med vægge og døre. Hvis Mutt glemmer navnet på en funktion, kan han nu slå det op, hvilket stadig tager 30 sekunder, eller han kan gå ind og spørge Jeff, hvilket nu tager 45 sekunder og kræver at han rejser sig (hvilket ikke er let, programmørers gennemsnitlige fysiske form taget i betragtning!). Så han slår det op. Han har altså mistet 30 sekunders produktivitet, men han sparer Jeff for 15 minutter. Ahhh!

9. Bruger I det bedste værktøj, man kan få?
At skrive kode i et kompileret sprog, er en af de sidste ting, der stadig ikke kan gøres hurtigt på en simpel hjemmecomputer. Hvis det tager mere end blot få sekunder at kompilere, vil det spare jer tid at anskaffe de seneste og bedste computere. Hvis det bare tager 15 sekunder at kompilere, kommer programmørerne til at kede sig, og giver sig til at læse The Onion, hvilket holder dem hen og koster timers arbejde.

At debugge GUI-kode med en enkelt monitor, er besværligt, hvis ikke direkte umuligt. Hvis man skriver GUI-kode, vil to monitorer gøre livet lettere.

De fleste programmører bliver på ét eller andet tidspunkt nødt til at manipulere med bitmapbilleder til ikoner eller værktøjspaletter, men de fleste programmører har ikke et anstændigt billedredigeringsværktøj til rådighed. At bruge Microsoft Paint til at manipulere billeder med, er til grin, men det er, hvad de fleste programmører er nødt til.

På mit sidste arbejde blev systemadministratoren ved med at sende mig en automatisk spam mail, der brokkede sig over at jeg brugte mere end .. ja .. 220 megabytes på serveren. Jeg pointerede, at med prisen på harddiske for tiden, var dette forbrug væsentligt billigere end den mængde toiletpapir, jeg brugte. At bruge blot 10 minutter på at rense ud i min mappe p serveren, ville være et utroligt tab af produktivitet.

På de bedste hold passer man på ikke at plage sine programmører. Selv små frustrationer, skabt af underlegne værktøjer, hober sig op, og ender med at gøre programmøren irriteret og utilfreds. Og en utilfreds programmør, er en uproduktiv programmør.

Dertil kommer... programmører kan let bestikkes ved at give dem det nyeste og sejeste software og hardware. Det er en meget billigere måde at få dem til at arbejde for dig, end rent faktisk at give konkurrencedygtige lønninger!

10. Har I testere?
Hvis et hold ikke har dedikerede testere, mindst én for hver to eller tre programmører, så leverer det enten fejlbehæftede produkter eller også spilder det penge ved at bruge programmører til 800 kroner i timen til at udføre arbejde, der kan gøres af en tester til 200 kroner i timen. At undvære testere er en så dårlig økonomisk strategi, at jeg simpelthen er målløs over hvor mange, der ikke indser det.

Læs Top Five (Wrong) Reasons You Don't Have Testers, en artikel jeg har skrevet om emnet.

11. Skriver jobansøgere kode under deres jobsamtale?
Ville du ansætte en tryllekunstner uden at bede ham om at vise dig et par tricks? Selvfølgelig ikke.

Ville du hyre en kok til dit bryllup uden at smage dennes mad? Jeg tvivler. (Med mindre det er moster Anna, og hun ville hade dig for evigt, hvis du ikke lod hende lave sin "berømte" tærte med hakket lever).

Alligevel bliver programmører hver dag ansat baseret på et imponerende C.V., eller fordi intervieweren synes, det var rart at tale med dem. Eller de bliver stillet trivielle spørgsmål ("hvad er forskellen på CreateDialog() og DialogBox()?"), hvilket kan besvares ved at kigge i dokumentationen. Det er ligemeget, om de har lært masser af triviel viden, men det betyder noget, om de er i stand til at producere kode. Eller, værre endnu, de bliver stillet et "AHA!"-spørgsmål — den type, der er lette, når man kender svaret, men umulige, hvis man ikke ikke gør.

Lad venligst være med det. Gør, hvad du vil under jobsamtaler, men sørg for at få ansøgeren til at skrive noget kode (se flere råd i min artikel  Guerrilla Guide to Interviewing).

12. Gennemfører I uformelle usabilitytests?
Når man laver usabilitytest ude på gangen, tager man den første, den bedste person, der går forbi ude på gangen, og tvinger dem til at prøve den kode, man lige har skrevet. Gør det med fem forskellige mennesker, og på den måde finder du 95% af de usabilityproblemer, der er med din kode.

Godt brugergrænsefladedesign er ikke så svært, som du måske tror, og det er vigtigt, hvis du vil have kunder til at elske og købe dit produkt. Du kan læse min  gratis online bog om UI-design, en kort gennemgang for programmører.

Men det vigtigste ved brugergrænsefladen er, at hvis man viser sit program til en håndfuld mennesker (fem eller seks er faktisk nok), lærer man hurtigt, hvad de største problemer måtte være. Læs Jakob Nielsen's artikel, der forklarer hvorfor. Selv hvis end evner til brugergrænsefladedesign er sparsomme, bliver resultatet langt bedre, hvis man tvinger sig selv til at gennemføre uformelle tests på gangen.

Fire anvendelsesområder til Joel-testen

1. Bedøm din egen organisation, og fortæl mig, hvordan den klarer sig, så jeg har noget at sludre om.
2. Hvis du leder et hold programmører kan du bruge denne checkliste til at sikre dig, at dit hold arbejder optimalt. Når du når op på 12, kan du lade dine programmører være alene, og istedet selv arbejde fuld tid med at forhindre forretningsfolkene i at genere dem.
3. Hvis du overvejer at begynde som programmør et sted, kan du spørge din potentielle arbejdsgiver, hvordan de klarer sig i testen. Hvis de ikke klarer sig så godt, skal du sikre dig, at du får autoritet til at kunne ændre tingene. Ellers ender du med at blive frustreret og uproduktiv.
4. Hvis du er investor og forsøger at vurdere er hold programmører, eller hvis dit softwareselskab overvejer at fusionere med et andet, kan denne test bruges som tommelfingerregel.