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)

Je hebt wel eens van die dagen dat je gewoon niets gedaan krijgt.

Ik kom op kantoor, klooi wat aan, check email elke 10 seconden, zwerf over het internet, doe wat van die zinloze dingen als mijn American Express betalen. Maar echt aan het werk gaan, code kloppen, wil gewoon niet lukken.

Deze eindeloze, onproductieve fasen duren meestal een dag of twee. Maar er zijn ook periodes geweest gedurende mijn carrière als developer dat ik gewoon weken aaneen niets zinnigs gedaan kreeg. Ik had geen inspiratie, zoals dan wel eens gezegd wordt. Ik ben er met mijn kop niet bij. Sterker nog, ik ben nergens.

Iedereen heeft stemmingswisselingen; de een heeft er meer last van dan de ander, bij sommige mensen zijn ze nauwelijks waarneembaar, bij anderen heel sterk, tot ophouden met functioneren toe. De niet productieve dagen lijken een correlatie te hebben met de mindere, sombere dagen.

Het doet me denken aan de onderzoekers die beweren dat mensen in feite geen controle hebben over hun eetlust, waardoor elk dieet gedoemd is om van korte duur te zijn en mensen altijd op hun natuurlijke gewicht terugvallen. Misschien kan ik als software ontwikkelaar niet echt controleren wanneer ik productief ben. De tragere dagen moet ik dan voor lief nemen en goedmaken op de snellere dagen, hopend dat het gemiddeld aantal lijnen code zal volstaan om me tewerkgesteld te houden.

Wat me het gekst maakt is dat ik me sinds mijn eerste baan realiseer dat ik als developer gemiddeld zo'n twee à drie uur per dag productief kan programmeren. Toen ik een zomerstage had bij Microsoft, vertelde een mede-stagiair me dat hij elke dag slechts van 12 tot 17 uur kwam werken. Vijf uurtjes, minus een half uur lunch en toch was zijn team gek op hem omdat hij meer gedaan kreeg dan het gemiddelde. Ik heb gemerkt dat dat voor mij ook werkt. Ik voel me wel wat schuldig als ik zie hoe hard iedereen om me heen schijnt te werken en ik maar twee à drie uur per dag effectief werk, en nog ben ik een van de meest productiefste leden van het team. Dat is waarschijnlijk waarom Peopleware en XP staan op het elimineren van overuren en een strikte werkweek van 40 uur voorschrijven. Ze doen dit in de vaste overtuiging dat de productiviteit van een team hierdoor zeker niet zal verminderen.

Het zijn echter niet de dagen dat ik "slechts" twee uurtjes gedaan krijg waar ik me zorgen om maak. Het zijn de dagen waarop ik niets gedaan krijg waar ik me zorgen om maak.

Ik heb daar veel over gepiekerd. Ik heb geprobeerd me te herinneren wanneer ik het meeste werk gedaan kreeg in mijn carrière. Waarschijnlijk was het toen Microsoft me verhuisde naar een prachtig nieuw kantoor met grote ramen met een uitzicht over een mooie stenen tuin vol met kersenbomen die in bloei stonden. Alles liep op rolletjes. Maandenlang ben ik non-stop bezig geweest met de gedetailleerde specificaties voor Excel Basic -- een monumentale stapel papier, dat tot in het kleinste detail een enorm object-model en programmeeromgeving omschrijft. Ik stopte werkelijk nooit. Toen ik naar Boston moest om naar MacWorld te gaan nam ik mijn laptop mee, en heb op een gezellig terrasje de Window class verder zitten documenteren.

Wanneer je eenmaal in zo'n stroomversnelling zit is het niet moeilijk om door te blijven gaan. Veel van mijn dagen zien er als volgt uit: (1) naar mijn werk gaan (2) email controleren, beetje surfen enz. (3) besluiten dat ik net zo goed eerst even kan gaan lunchen voor ik aan het echte werk begin (4) terug komen van lunch (5) email controleren, beetje surfen enz. (6) besluiten dat ik nu toch echt iets zinnigs moet gaan doen (7) email controleren, beetje surfen enz. (8) nog maar een keer het besluit nemen dat ik toch echt iets moet gaan doen (9) die vervloekte editor starten (10) non-stop code kloppen tot ik niet meer weet dat het reeds half acht is.

Ergens tussen stap 8 en 9 schijnt een bug te zitten want ik kan niet altijd voorbij dat punt komen.

Het enige moeilijke voor mij is beginnen. Een object in rust heeft de neiging in rust te blijven. Iets ontzettend zwaar in mijn hoofd heeft het enorm moeilijk om op gang te komen, maar eens het zover is, is het ook niet meer te stoppen. Zoals een fiets volgeladen met bepakking voor een lange tocht, als je begint te fietsen met al die last op je fiets, is het moeilijk om te geloven hoe zwaar het is het ding alleen al aan het rollen te krijgen, maar eens je fiets rolt, is het net alsof je op een fiets zonder bepakking rijdt.

Wellicht is dit de sleutel tot productiviteit, gewoon beginnen. Wanneer pair programming werkt is het misschien omdat wanneer je een pair programming sessie plant met je buddy, je elkaar verplicht te beginnen.

Toen ik als Israëlisch paratrooper werkte kwam er een generaal langs om ons een kleine speech te geven over strategie. In infanteriegevechten, vertelde hij, is er maar één strategie: Vuren en Bewegen. Je beweegt in de richting van je vijand terwijl je je wapen afvuurt. Het afvuren dwingt hem dekking te zoeken zodat hij niet terug kan schieten. (Dat is wat soldaten bedoelen met "cover me". Het betekent, "schiet op de vijand zodat hij dekking moet zoeken en niet kan schieten terwijl ik hier over straat ren." Het werkt.) De beweging laat je toe terrein te winnen en dichter bij je vijand te komen, waar jouw schoten meer kans maken iets te raken wanneer je de trekker overhaalt. Wanneer je niet beweegt beslist de vijand wat de volgende stap is en dat is niet wat je wilt. Wanneer je niet schiet zal de vijand op jou schieten, waardoor je vastzit.

Dit heb ik lang onthouden. Het viel me op dat bijna elke vorm van militaire strategie, van luchtgevechten tot grootschalige marinemaneuvres, gebaseerd zijn op het idee van Vuren en Bewegen. Het duurde nog eens 15 jaar voordat ik me realizeerde dat het principe van Vuren en Bewegen is hoe je dingen gedaan krijgt in het leven. Je moet een beetje vooruit gaan, elke dag. Het maakt niet uit of je spaghetticode schrijft en niemand het wil. Zolang je vooruit blijft bewegen, continu code kloppen en fixen, is de tijd aan jou kant. Kijk uit wanneer je tegenstanders op je vuren. Willen ze je alleen maar dwingen om bezig te zijn met reageren op hun acties zodat jij niet meer vooruit kunt komen?

Denk aan de geschiedenis van Microsoft data access strategieën. ODBC, RDO, DAO, ADO, OLEDB, nu ADO.NET - Allemaal Nieuw! Was dit werkelijk nodig? Het resultaat van een incompetente ontwerpgroep die data access elk godvergeten jaar opnieuw wil uitvinden? (Waarschijnlijk wel.) Maar het resultaat is alleen maar dekkingsvuur. De concurrentie heeft geen andere keuze dan te porten en proberen Microsoft bij te houden, zodat ze geen tijd kunnen besteden aan nieuwe features. Kijk eens beter naar het softwarelandschap. Bedrijven die het goed doen zijn de bedrijven die het minst vertrouwen op grote bedrijven en dus niet al hun tijd hoeven te spenderen aan het herimplementeren en fixen van bugs die alleen maar in Windows XP voorkomen. De bedrijven die struikelen zijn zij die teveel tijd besteden aan het lezen van theebladeren om de toekomstige ontwikkelingen van Microsoft te voorspellen. Mensen maken zich zorgen over .NET en besluiten hun hele architectuur om te gooien voor .NET omdat ze denken dat ze wel moeten. Microsoft schiet op je, en dat is alleen maar spervuur zodat zij vooruit kunnen komen en jij niet, omdat dat is hoe het spel gespeeld dient te worden. Ga jij Hailstorm ondersteunen? SOAP? RDF? Ondersteun je het omdat je klanten het nodig hebben of omdat iemand op je schiet en je het gevoel hebt dat dat de manier is waarop je moet reageren? De salesteams van grote bedrijven begrijpen spervuur. Zij gaan naar hun klanten en zeggen: "Ok, je hoeft niet van ons te kopen. Koop bij de beste. Maar let er dan wel op dat het product (XML / SOAP / CDE / J2EE) ondersteunt want anders Zit Je Vast". Wanneer de kleine bedrijfjes vervolgens komen om die account binnen te halen, horen ze volgzame CTO's vragen "Heb je J2EE?" en zij moeten al hun tijd verdoen om in J2EE te bouwen, zelfs als het geen nieuwe verkopen inhoudt, en hen ervan weerhoudt zichzelf te onderscheiden. Het is een "checkbox feature" -- je doet het omdat het checkboxje zegt dat je het moet hebben, maar niemand zal het gebruiken of zelfs maar nodig hebben. Het is een spervuur.

Voor kleine bedrijfjes als het mijne betekent Vuren en Bewegen twee dingen. Je moet de tijd aan je zijde hebben, en je moet vooruit bewegen, elke dag. Vroeger of later zul je winnen. Alles wat ik gisteren voor elkaar heb gekregen is het kleurenschema in FogBUGZ een beetje verbeteren. Dat maakt niet uit. Het wordt constant beter. Elke dag wordt onze software beter en beter en krijgen we meer klanten en dat is wat er toe doet. Tot de tijd dat we een bedrijf zijn van het formaat van Oracle hoeven we niet te denken aan grootse strategieën. We hoeven slechts elke ochtend te komen en op de een of andere manier de editor te starten.