Joel on Software

Joel on Software   Joel over Software

 

Andere "Joel on Software" artikelen in het Nederlands

Andere "Joel on Software" artikels in het Engels

Email de auteur (uitsluitend in het Engels)

 

De Joel Test: 12 Stappen naar Betere Code


Door Joel Spolsky
Vertaald door Koen Verheyen
Geredigeerd door Yves Goetgeluck
9. 8. 2000

Ooit gehoord van SEMA? Een vrij esoterisch systeem om te meten hoe goed een software team is. Wacht! Niet op de link klikken! Het zal je ongeveer zes jaar kosten enkel en alleen al om te verstaan waarover het gaat. Dus heb ik m'n eigen, hoogst onverantwoorde en slordige test om de kwaliteit van een software team te meten. Het geweldige eraan is dat het beslag legt op slechts 3 minuten van je kostbare tijd. Met de ingewonnen tijd kan je geneeskunde gaan studeren.

De Joel Test

  1. Gebruik je source controle?
  2. Maak je builds in 1 stap?
  3. Maak je dagelijkse builds?
  4. Gebruik je een bug database?
  5. Verbeter je je bugs vóór je nieuwe code schrijft?
  6. Heb je een bijgewerkte planning?
  7. Heb je specificaties?
  8. Hebben ontwikkelaars een rustige werkomgeving?
  9. Gebruik je de best beschikbare tools?
  10. Heb je testers?
  11. Schrijven sollicitanten code tijdens hun interview?
  12. Voorzie je voorbijgangerstesten?  

Het leuke aan de Joel Test is dat je snel een duidelijk ja of nee krijgt op elke vraag. Geen ingewikkelde lijnen-code-per-dag of gemiddeld-aantal-bugs-per-kern-functie berekening dus. Geef je team gewoon 1 punt per ja antwoord. De knaller van de Joel Test is dat je hem absoluut niet moet gebruiken om te checken of je kerncentrale wel veilig is.

Een 12 is perfect en een 11 aanvaardbaar, maar scoor je 10 of lager dan zit je zwaar in de nesten. Spijtig genoeg werken de meeste software ontwikkelaars met een magere 2 of 3 en hebben ze dringend hulp nodig, want bedrijven als Microsoft draaien voltijds op 12.

Natuurlijk zijn er ook andere factoren die bepalend zijn voor je succes. Meer bepaald, als je een geweldig software team hebt dat werkt aan een product waaraan niemand boodschap heeft, wel, dan zal niemand er naar omkijken. En je kan je best een team van "cowboys" indenken die al deze regels aan hun laars lappen en toch de onwaarschijnlijste en revolutionairste software produceren. Maar als je, onder gelijkaardige omstandigheden, deze 12 regels voor je kan laten werken, beschik je over een gedisciplineerd team dat systematisch kan opleveren.

1. Gebruik je source controle?

Ik heb commerciële pakketen gebruikt en het gratische CVS en geloof me, CVS is prima. Maar zonder source controle ga je je ontwikkelaars stresseren in pogingen ze goed te laten samenwerken. Ontwikkelaars kunnen onmogelijk weten wat anderen hebben gewijzigd. Fouten terugdraaien is lastig. En ook leuk is dat de code zelf wordt uitgecheckt naar de harde schijf van elke ontwikkelaar -- Ik heb nog nooit een project dat source controle gebruikt een hoop code weten verliezen.

2. Maak je builds in 1 stap?

Met andere woorden: in hoeveel stappen maak je een verzendingsklaar product startend vanuit de laatste versie van je code? Goede teams hebben één enkel script dat van niets startend de code uitcheckt, elke lijn hercompileert, de EXEs maakt in alle vereiste variaties, talen en #ifdef combinaties, het installatiepakket bouwt en het distributiemedium genereert -- CDROM layout, download site, wat dan ook.

Indien dit proces meer dan één stap vergt, is het onderhevig aan fouten. En hoe korter je bij de opleveringsdatum komt, hoe sneller je je laatste bug wil kunnen corrigeren, de ultime EXEs wil maken, etc. Als het je dus 20 stappen kost om de code te compileren, het installatiepakket te bouwen, etc., wordt je daar gek van en ga je stomme fouten maken.

Daarom is de laatste firma waar ik werkte overgestapt van WISE naar InstallShield. We eisten dat de installatie werkte via een script, automatisch, 's nachts en gestart door NT scheduler. En WISE kon je niet starten via NT scheduler en vloog er dus uit. (De aardige kerels van WISE verzekeren me dat hun laatste versie wel degelijk nachtelijke builds toelaat)

3. Maak je dagelijkse builds?

Met source controle kan het gebeuren dat een ontwikkelaar per ongeluk iets incheckt dat de build breekt. Ze hebben bijvoorbeeld een nieuwe source toegevoegd en alles compileert perfect op hun eigen machine, maar ze vergaten de source toe te voegen aan de code repository. Ze vergrendelden hun machine en gingen vrolijk en niets vermoedend naar huis. Alleen kan niemand nu nog verder en moeten zij ook - veel minder vrolijk - naar huis.

Een build breken is zo erg - en komt zo vaak voor - dat het helpt om dagelijkse builds te maken zodat gebroken builds niet ongemerkt blijven. Bij grote teams is een dagelijkse build - tijdens de middag bijvoorbeeld - een goede manier om ervoor te zorgen dat breuken onmiddellijk worden hersteld. Iedereen checkt vóór de lunch al zijn beschikbare code in en als ze terug komen is de build klaar. Is alles in orde, prima! Iedereen checkt de laatste versie uit en gaat weer aan het werk. Indien de build faalt, herstel je die terwijl alle anderen gewoon voortwerken met de werkende pre-build code.

Bij het Excel team hadden we de regel dat iemand die de build brak, bij wijze van "straf", het buildproces moest babysitten tot iemand anders het brak. Het was een geweldige stimulans om geen build te laten breken en een goed rotatiesysteem om iedereen te laten kennismaken met het buildproces.

Lees meer over dagelijkse builds in m'n artikel Dagelijkse Builds zijn je Vriend.

4. Heb je een bug database?

Het kan me niet schelen wat je ervan vindt. Als je code schrijft - zelfs in een één-persoonsteam - zonder georganizeerde database van alle gekende bugs, ga je lage kwaliteit leveren. Veel ontwikkelaars denken dat ze de lijst gewoon kunnen onthouden. Onzin. Ik kan nooit meer dan twee of drie bugs tegelijk onthouden en de volgende morgend - of in de verzendingchaos - zijn ze vergeten. Je hebt absoluut nood aan een formeel systeem om bugs bij te houden.

Bug databases kunnen complex of simpel zijn. Een minimale nuttige database moet van elke bug bijhouden:

  • volledige stap per stap beschrijving om de bug te reproduceren
  • het verwachte gedrag
  • het (foutieve) vastgestelde gedrag
  • aan wie de bug is toegekend
  • of de bug al is verbeterd

Als de complexiteit van je bugopvolgingssysteem het enige is wat je tegenhoud, maak dan simpelweg een tabel met 5 kolommen met deze cruciale velden en begin het te gebruiken.

Meer over bug tracking, lees Pijnloze Bug Opvolging

5. Verbeter je je bugs vóór je nieuwe code schrijft?

De allereerste versie van Microsoft Word voor Windows werd beschouwd als een "dodentocht" project. Het duurde eeuwig. Het bleef maar uitlopen. Het hele team werkte de gekste uren, het project werd keer op keer op keer uitgesteld en de stress was verschikkelijk. Toen het verdomde ding dan eindelijk werd opgeleverd, jaren later, zond Microsoft het hele team naar Cancun op vakantie en zat toen samen voor een serieus gewetensonderzoek.

Wat ze zich realizeerden was dat de projectmanagers zo zwaar hamerden op het houden van "de planning", dat ontwikkelaars door het coderingsproces heen raasden, erg slechte code producerend omdat bugs verbeteren toch geen deel uitmaakte van de formele planning. Ze deden geen inspanning om de aantal bug laag te houden. Integendeel. Het verhaal gaat dat een ontwikkelaar die de hoogte van een tekstlijn moest berekenen simpelweg schreef "return 12;" en op het bugrapport wachtte waarin werd gemeld dat de functie niet altijd het correcte antwoord leverde. De planning was niets anders dan een lijst functies die nog in bugs moesten worden omgezet. In de post-mortem werd dit omschreven als de "oneindige defecten methodologie".

Het probleem werd verholpen doordat Microsoft universeel de "nul defecten methodologie" invoerde. Veel ontwikkelaars in de firma grinnikten omdat het leek alsof het management dacht dat ze het aantal bugs konden verminderen bij dekreet. Eigenlijk betekende "nul defecten" dat op elk willekeurig ogenblik de hoogste prioriteit lag bij bugs-eliminatie, vóór er nieuwe code werd geschreven. En dit is waarom.

In het algemeen, hoe langer je wacht voordat je bugs aanpakt, hoe duurder (qua tijd en geld) het is om ze te verbeteren.

Een voorbeeld. Als je een typ- of syntax-fout maakt die door de compiler wordt opgemerkt, is verbeteren in weze triviaal.

Als je een bug ziet de eerste keer dat je je code uitprobeert, dan zal je ze in minder dan geen tijd kunnen oplossen want alles zit nog vers in je geheugen.

Als je een bug vindt in code die je een paar dagen geleden schreef, dan zal het een tijdje duren om de oorzaak te vinden, maar terwijl je de code herleest zal je je alles weer herinneren en kan je het probleem in een redelijke tijd oplossen.

Maar als je een bug vindt in code van een paar maanden oud, ben je wellicht veel over die code vergeten en wordt het lastiger om op te lossen. Tegen dan ben je allicht iemand anders' code aan het aanpassen - en die kan op Aruba met vakantie zijn. In dat geval is bugs verbeteren als wetenschap: je moet traag, methodisch en scrupuleus zijn en je weet nooit hoeveel tijd het zal kosten om de oplossing te ontdekken.

En als je bugs vindt in code die al is verscheept, dan zal het je veel geld gaan kosten om die verbeterd te krijgen.

Dat is één reden om bugs onmiddellijk aan te pakken: het vraagt minder tijd. Maar er is nog een andere reden, gerelateerd aan het feit dat je beter kan inschatten hoelang het schrijven van nieuwe code vraagt dan inschatten hoelang het duurt om een bug op te lossen. Als ik je bijvoorbeeld vraag hoelang het duurt om code te schrijven die een lijst sorteert, kan je me allicht een vrij goede schatting geven. Maar als ik je vraag op te sporen waarom je code niet werkt eens Internet Explorer 5.5 geïnstalleerd is, dan kan je er zelfs niet naar raden omdat je per definitie niet weet waardoor het probleem wordt veroorzaakt. Het kan 3 dagen vergen, of slechts 2 minuten.

Dat betekent dat als je een planning hebt met veel hangende bugs, je planning onbetrouwbaar is. Heb je echter al de gekende bugs verbeterd en alles wat overblijft is nieuwe code, dan zal je planning onstellend veel accurater zijn.

En ook plezierig aan een géén bugs situatie, is dat je veel sneller kan reageren op de concurrentie. Sommige ontwikkelaars zien dit als het product ten allentijde verzendingsklaar houden. Als je concurrent met een 'killer' functie uitpakt en je klanten steelt, dan implementeer je gewoon die functie en verzend het terstond, zonder eerst een groot aantal opgehoopte bugs te moeten aanpakken.

6. Heb je een bijgewerkte planning?

Wat ons bij planningen brengt. Als je code ook maar enigszins van belang is voor het bedrijf, dan zijn er massa's redenen waarom het belangrijk is dat het bedrijf weet wanneer de code klaar is. Ontwikkelaars zijn legendarisch ontwijkend als het aankomt op plannen."Het is klaar als het af is!" roepen ze de bedrijfsmensen toe.

Spijtig genoeg snijdt dat geen hout. Een bedrijf moet gewoon teveel dingen beslissen lang voor de verzending: demos, beurzen, advertensies, etc. En dat kan enkel door te plannen en je aan die planning te houden.

Een ander elementair gegeven in verband met plannen is dat het je dwingt te beslissen welke functies je erin gaat steken. En daarna dwingt het je om de minst belangrijke functies te laten vallen, eerder dan te vervallen in 'featuritis' (ook gekend als uitdijnende scoop).

Je aan je planning houden hoeft niet lastig te zijn. Lees m'n artikel Pijnloze Software Planning dat een eenvoudige manier beschrijft om geweldige planningen op te stellen.

7. Heb je een specificatie?

Specs schrijven is als flossen: iedereen vindt het belangrijk, maar niemand doet het.

Ik weet niet zeker waarom dit zo is, maar wellicht omdat ontwikkelaars het schrijven van documenten haten. Met als resultaat dat als teams van uitsluitend ontwikkelaars een probleem aanpakken, ze hun oplossing liever als code uitdrukken dan als document. Ze duiken liever direct in de code dan eerst specs te schrijven.

Als je op problemen botst tijdens de ontwerpfase, kan je die makkelijk oplossen door een paar lijnen tekst. Eens de code geschreven, is de kost van verbeteren echter drastig hoger, zowel emotioneel ( ze haten het code weg te gooien ) als qua tijd en is erdus een weerstand tegen het verbeteren van fouten. Software geschreven zonder van een spec te vertrekken eindigt meestal als slecht ontworpen en de planning raakt uit controle. Dit lijkt het probleem geweest te zijn bij Netscape, waar de eerste vier versies zich ontwikkelden tot zulk een puinhoop dat het management stompzinnig besloot alles weg te gooien en te herbeginnen. Waarna ze dezelfde fout opnieuw maakten met Mozilla, een monster creërend dat volledig uit de hand liep en jaren nodig had om in alfa stadium te geraken.

Mijn stokpaardje is dat dit probleem kan worden opgelost door ontwikkelaars te leren minder terughoudende schrijvers te worden door ze naar een intensive cursus schrijven te zenden. Een andere oplossing is intelligente programma managers aan te nemen die geschreven specs produceren. In beide gevallen moet je de simpele regel "geen code zonder spec" afdwingen.

Leer alles over specs schrijven door m'n 4-delige serie te lezen.

8. Hebben ontwikkelaars een rustige werkomgeving?

Er zijn uitgebreid gedocumenteerde productiviteitsstijgingen door bekwame werkers ruimte, rust en privacy te geven. Het klassieke software management boek Peopleware beschrijft deze productiviteitsvoordelen extensief.

Dit is het knelpunt. We weten allemaal dat bekwame mensen het beste werken als ze in hun "ritme" geraken, ook gekend als "in de zone" zitten, waar ze volledig op hun werk zijn geconcentreerd en ze hun omgeving totaal hebben buiten gesloten. Ze verliezen alle gevoel voor tijd en produceren schitterende dingen door pure concentratie. Dat is wanneer ze al hun productieve werk doen. Schrijvers, ontwikkelaars, wetenschappers en zelfs voetballers kunnen je vertellen over het "in de zone" zitten.

Maar "in de zone" komen is niet zo makkelijk. Als je het probeert te timen, dan duurt het ongeveer 15 minuten voor je je maximale productiviteit bereikt. Soms, als je moe bent of al veel creatief werk hebt verzet, kan je zelfs helemaal niet meer "in de zone" komen en spendeer je de rest van de dag rondslenterend, surfend of Tetris spelend.

Een ander probleem is dat je weer makkelijk uit "de zone" wordt geslagen. Lawaai, telefoons, lunchen, eventje buitenwippen voor een ijsje en onderbroken worden door collegas - vooral onderbroken worden door collegas - kunnen je allemaal uit de zone halen. Als een collega je een vraag stelt, je daarvoor 1 minuut onderbreekt maar je tegelijk ook zwaar genoeg uit de zone haalt zodat het je een half uur kost om terug productief te worden, dan is je gemiddelde productiviteit in ernstig gevaar. Als je werkt in een lawaaierige marktvloer waar de op caffeine draaiende dotcoms zo gek op zijn, met door de telefoon schreeuwende marketingmensen naast ontwikkelaars, dan zal de productiviteit als een baksteen dalen omdat je bekwame mensen steeds weer worden gestoord en maar niet in de zone geraken.

Met ontwikkelaars is het extra lastig. Productiviteit hangt af van het vermogen veel kleine details tegelijk in je korte termijn geheugen te jongleren. Elke onderbreking laat al die details door elkaar neerstorten. Als je je werk hervat kan je je die detail niet herinneren ( namen van lokale variabelen, waar je zat in de implementatie van dat zoekalgoritme ) en je moet die dingen steeds weer gaan opzoeken, wat je erg vertraagt tot alles weer netjes in je geheugen zit.

Dit is het simpele rekensommetje. Stel (zoals de bewijzen suggereren) dat als we een ontwikkelaar - al is het maar een minuutje - onderbreken, we eigenlijk 15 minuten productiviteit wegblazen. In dit voorbeeld zitten 2 ontwikkelaars Klaas en Peter in open werkboxen naast elkaar in een sinds Dilbert beruchte standaard vetmesterij. Peter kan zich de naam niet herinneren van de Unicode versie van de strcpy functie. Ofwel zoekt hij het op - wat 30 seconden vraagt, of hij vraagt het aan Klaas - slechts 15 seconden. Omdat hij toch vlak bij Klaas zit, vraagt hij het maar aan Klaas. Die raakt daardoor afgeleid en verliest zo 15 minuten aan productiviteit (terwijl Peter 15 seconden winst boekt).

Nu zetten we ze in afzonderlijke kantoren met muren en deuren. Peter kan zich de naam van die functie niet herinneren en kan die opzoeken - wat nog steeds 30 seconden vraagt - of hij kan het gaan vragen - wat nu echter 45 seconden vergt plus de moeite van op te staan (nooit makkelijk gezien het gemiddelde fitheidsniveau van ontwikkelaars). Dus hij zoekt het op. Peter verliest nu dus 30 seconden maar we hebben Klaas 15 minuten tijdsverlies bespaard. Ahhh!

9.Gebruik je de best beschikbare tools?

Code schrijven in een gecompileerde taal is één van de laatste dingen die je niet zomaar kan doen op een standaard grootwarenhuis PC. Als je compilatie meer dan een paar seconden duurt dan zal de aanschaf van het laatste supersnelle computer je tijd gaan besparen. Als diezelfde compilatie je zelfs 15 seconden kost, raken ontwikkelaars verveeld terwijl de comuter werkt en schakelen over op het lezen van "The Onion", wat hun interesse vasthoudt en uren aan productiviteit kost, wat je snel zal ontdekken als je op de link klikt.

GUI code debuggen met slechts 1 monitor is pijnlijk zoniet onmogelijk. Als je GUI code schrijft zal een tweede monitor alles zoveel eenvoudiger maken.

De meeste ontwikkelaars moeten uiteindelijk bitmaps voor iconen en werkbalken manipuleren, en de meesten hebben gewoonweg geen goede bitmap editor. Proberen Microsoft Paint te gebruiken om bitmaps te manipuleren is een lachertje, maar toch is het dat wat de meesten moeten doen.

Op m'n laatste job bleef de systeembeheerder via geautomatiseerde spam maar klagen dat ik meer dan ... geloof het of niet ... 220 megabytes op de harde schijf van de server innam. Ik wees hem erop dat gezien de prijs van hardware dezer dagen, de kost van de schijf vele keren minder was dan van het toiletpapier dat ik gebruikte. Zelfs een luttele 10 minuten durende opkuis van mijn bestanden zou een gigantisch verlies aan productiviteit betekenen.

Top ontwikkelingsteams martelen hun ontwikkelaars niet. Zelfs de kleinste frustratie veroorzaakt door tekortschietende tools cumuleert zich en maakt ontwikkelaars nors en ongelukkig. En een norse ontwikkelaar is een onproductieve ontwikkelaar.

Daarenboven... ontwikkelaars laten zich makkelijk omkopen met de nieuwste technische snufjes. Een véél gekopere wijze om ze aan het werk te krijgen dan ze een competitief salaris te moeten betalen!

10. Heb je testers?

Als je team geen eigen toegewezen testers heeft, tenminste één per twee of drie ontwikkelaars, verzend je buggy producten, of je verspilt geld door €3000/maand ontwikkelaars het werk te laten doen dat even goed gedaan kan worden door €1500/maand testers. Beknibbelen op testers is zulk een waanzinnig valse besparing dat ik simpelweg achterover sla als mensen dat niet inzien.

Lees Top Vijf (Foutieve) Redenen Waarom Je Geen Testers Hebt, een artikel dat ik hierover schreef.

11. Schrijven sollicitanten code tijdens hun interview?

Zou je een goochelaar huren zonder hem te vragen wat van zijn truken te laten zien ? Tuurlijk niet.

Zou je een traiteur huren voor je trouwfeest zonder eerst even zijn eten te proeven? Ik betwijfel het. (Tenzij tante Jeanne is, en ze je eeuwig zou haten als ze haar "befaamde" rijstpudding niet mag serveren).

En toch worden elke dag ontwikkelaars aangeworven op basis van een impressionant CV omdat de interviewer hen leuk vond tijdens het gesprek. Of ze krijgen triviale vragen ("Geef het verschil tussen CreateDialog() en DialogBox()") die je zo uit de documentatie kan halen. Het kan je niet schelen of ze duizenden trivialiteiten over programeren kunnen herinneren, je wilt dat ze code kunnen produceren. Of nog erger, ze krijgen "AHA!" vragen: het soort vragen dat eenvoudig is als je het antwoord kent, maar als je het niet kent zijn ze gewoon onmogelijk.

Stop daar aub mee. Doe verder wat je wil tijdens interviews, maar laat de kandidaten wat code schrijven. (Voor meer advies, lees m'n Guerilla Gids over Interviewen)

12. Voorzie je voorbijgangerstesten?

Een voorbijgangerstest doe je door de volgende persoon die in de gang voorbij komt bij het nekvel te grijpen en de code die je net schreef te laten uitproberen. Als je dit vijf mensen laat doen, zal je 95% leren van wat er te weten valt over de gebruiksvriendelijkheid van je code.

Goed gebruikersinterface-ontwerp is niet zo lastig als je wel denkt and het is cruciaal als je wil dat klanten van je producten houden en ook nog gaan kopen. Je kan m'n gratis online boek over gebruikersinterface-ontwerp lezen, "een korte handleiding voor programmeurs".

Maar het belangrijkste in verband met gebruikersinterfaces is dat als je je programma toont aan een paar mensen, (vijf of zes is al voldoende) je snel zal ontdekken waarmee ze het meest problemen hebben. Lees Jacob Nielsen's artikel dat uitlegt waarom. Zelfs als je geen gebruikersinterface-ontwerp kennis hebt, zo lang je jezelf tot voorbijgangerstesten dwingt - die overigens niets kosten - zal je gebruikersinterface véél, véél beter zijn.

Vier manieren om de Joel Test te gebruiken.

  1. Test je eigen werkgever en vertel me de score, zodat ik erover kan roddelen.
  2. Als je manager bent van een team ontwikkelaars, gebruik het als checklijst om zeker te zijn dat je team zo goed als moegelijk werkt. Als je 12 scoort kan je je team rustig alleen laten en je voltijds concentreren op het weghouden van bedrijfsmensen die hen proberen te storen.
  3. Als je moet beslissen of je een job aanneemt, vraag je werkgever in spé hoe ze doen op de test. Als het te laag is, zorg dat je genoeg macht hebt om in te grijpen. Zoniet zal je snel gefrustreerd en onproductief zijn.
  4. Ben je inversteerder die een estimatie doet van de waarde van een ontwikkelingssteam, of je firma wil fuseren, dan kan deze test een snelle en eenvoudige vingerwijzing geven.


De originele versie van dit artikel verscheen in het Engels onder de naam The Joel Test: 12 Steps to Better Code  

Joel Spolsky is de oprichter van Fog Creek Software, een klein softwarebedrijf in New York. Hij studeerde af aan de Yale universiteit, en heeft als programmeur en manager gewerkt bij Microsoft, Viacom en Juno.


De inhoud van deze pagina's vertegenwoordigt de mening van één persoon.
Alle inhoud Copyright ©1999-2005 door Joel Spolsky. Alle rechten voorbehouden.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky