De productiviteit van softwareontwikkelaars

Het ontwikkelen van software is voor leken vaak een mythische aangelegenheid. Jongens met t-shirts en brillen zitten dagen achter elkaar achter een computer ingewikkelde tekens in te kloppen. Ze stoppen alleen voor cola en pizza. En als je maar lang genoeg wacht dan is de software plotseling klaar. Degene die eerder met ontwikkelaars werkten, weten dat het zo niet gaat.

Programmeurs zijn serieuze  mannen die serieus met hun vak bezig zijn. Ja, er zijn in de westerse wereld relatief weinig vrouwen die software maken. Ontwikkelaars hebben in de afgelopen decennia geleerd dat de buitenwacht een beetje transparantie op prijs stelt. Die combinatie van professioneel werken en de vraag naar openheid heeft geleid tot een scala aan manieren waarop de opdrachtgever mee kan sturen in het ontwikkelproces. Maar hoe meet je nou of een ontwikkelaar productief is?

Productie wordt vaak uitgedrukt in stuks per uur, als in: een persoon plukt 20 kilo tomaten per uur. Productiviteit kun je dus uitdrukken in de hoeveelheid output die je krijgt bij een bepaalde hoeveelheid input. Werkt dit ook voor programmeurs? Wat produceren ontwikkelaars dan, wat is hun output? Een aantal mogelijkheden: het aantal regels code, het aantal computerprogramma’s of bijvoorbeeld het aantal nieuwe functionaliteiten of verholpen bugs.

Volgens Microsoft oprichter Bill Gates is het meten van productiviteit in regels code een onzinnige exercitie: “Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.” Een groot programma heeft inderdaad veel regels code, maar veel regels code wil niet zeggen dat het programma groot is. Het kan ook gewoon slecht ontworpen zijn. En daar komt nog bij dat het aantal regels code de opdrachtgever niets zegt.

Softwareontwikkelaars produceren geen regels code, maar functi0naliteiten. En die kun je tellen. Je kunt heel grof het aantal tellen, en je kunt dit verder verfijnen door functionaliteiten in te delen in groepen: klein, middel en groot. Als je een stapje verder gaat kun je iedere functionaliteit een waardering geven. Bijvoorbeeld van 1 tot 100. Zo heb je een kleine functionaliteit van 12 punten en een grote van 64. Samen goed voor een productie van 76. En als de ontwikkelaar daar 4 dagen mee bezig is geweest dan is zijn productiviteit 19 punten per dag.

Deze methode lijkt bijzonder (dat is hij ook), maar wordt eigenlijk al heel lang toegepast. Vroeger noemde men dit een functiepuntenanalyse, de tegenwoordige veel hippere term is scrum-punten. En dan maar zeggen dat programmeurs niet trend-gevoelig zijn! Hoe je het ook noemt en wat de subtiele verschillen ook mogelijk zijn, het idee is het zelfde: presenteer een functi0nele vraag aan ontwikkelaar en vraag hem hoeveel punten de bouw kost. Aan de hand van bepaalde tellingen kan vrij nauwkeurig een aantal punten worden bepaald.

Een softwareontwikkelaar levert functionaliteiten op waarbij de hoeveelheid uitgedrukt wordt in punten. Dit meet je iedere week om een gevoel te krijgen van de productiviteit. En daarmee dus ook wat de productie voor de komende week zal worden. Door met punten te werken is het mogelijkheid om redelijk exact te schatten hoeveel werk er af kan komen in een bepaalde periode. Of omgekeerd: hoeveel tijd nodig is om een bepaalde functionaliteit te bouwen.

Deze verbluffend simpele truc werkt in de praktijk erg goed en steeds meer ontwikkelaars passen hem toe. Te crux blijft echter zitten in het continu meten om een goede statistiek op te bouwen. Meten is weten.

Advertisements

Advies: maak je studie niet af

Toen ik jong was (vroeger) wist ik niet wat ik later wilde worden, maar je kan niet eeuwig op de HAVO of VWO blijven zitten! Op een bepaald moment komt de onherroepelijke vraag wat je wilt studeren. De studiekeuze wordt gepresenteerd als een cruciaal moment in iemands leven. Volgens studieadviseurs, ouders en glimmende brochures zal de studiekeus bepalen welk beroep je de rest van je leven zal uitvoeren. En het is waar: iemand die journalistiek studeerde zal niet plotseling gaan werken als huisarts.

Weinig mensen weten wat ze op hun achttiende de rest van hun leven willen doen. Maar, wat als blijkt dat je de verkeerde studie hebt gevolgd? Dat wil zeggen: je bent afgestudeerd, je hebt een paar jaar ervaring en komt tot de ontdekking dat het werk je totaal niet ligt. Of je hebt je studie halverwege afgebroken, leuk werk gevonden in een geheel ander vakgebied, en mist een theoretische basis om verder te komen. Kun je dan alsnog een studie oppakken?

Studeren wordt door ouders gepresenteerd als een once-in-a-life-time-opportunity. Dat is niet helemaal waar. Iedereen met goede wil kan ook op latere leeftijd nog een studie oppakken. Alleen, het is niet de makkelijkste weg. Een studie kost veel tijd. En als je een 40-urige werkweek hebt, dan kun je het luieren in de tuin voorlopig vergeten. Starten met een deeltijd-opleiding vereist een bepaalde mate van naïef enthousiasme. Als je weet waar je aan begint, dan begin je er niet eens aan.

Wanneer je eerder een studie hebt afgerond, dan is het volgen van een deeltijd-studie niet alleen een aanslag op de vrije tijd, maar ook op de portemonnee. Vanaf het komende collegejaar wordt het volgen van een tweede (Bachelor- of Master-)studie niet meer vergoed. De student betaalt het instellingscollegegeld. Dit bedrag is afhankelijk van de opleiding maar kan makkelijk oplopen tot 15.000 euro per jaar. Als je weet dat een beetje deeltijd-studie 8 jaar duurt, dan is een tweede studie dus volstrekt onbetaalbaar. Stop het geld liever in een vervroegd pensioen.

De mogelijkheid tot studeren staat open voor iedereen (van 18 tot 88). Desondanks is het advies om vroeg te gaan studeren nog even geldig als altijd. En, vanaf het komende collegejaar komt daar een extra advies bij: maak je studie niet af, daarmee vergooi je namelijk de mogelijkheid om ooit nog een tweede studie te kunnen betalen. Afstuderen is vanaf komend jaar zo ongeveer het domste wat je kunt doen.

Loon naar werken

In veel Nederlandse bedrijven is een werkweek van 40 uur de norm. Er zijn werkgevers die verwachten dat werknemers hier flexibel mee om gaan. In hun richting gerekend uiteraard. Daarnaast zijn er grote aantallen werknemers die het niet zo nauw nemen met de 40-uren-norm en geregeld meer uurtjes maken en zelfs werk mee naar huis nemen. Apart.

Is het terecht dat medewerkers meer uren maken dan contractueel verplicht? Wanneer je kijkt naar landen om ons heen, en dan met name naar onze linkerburen, dan lijkt Nederland een heel lui land. In Londen is een uitgebreide werkweek eerder norm dan uitzondering.

Het structureel overwerken is een interessant fenomeen. Ik ken bijvoorbeeld geen werkgevers die structureel meer salaris overmaken dan afgesproken. Dat lijkt mij het zelfde, al is het omgekeerd geredeneerd. Wanneer het gaat om arbeidsvoorwaarden maak je een afspraak en is er geen enkele reden waarom je iets anders zou doen of verwachten.

Voor werkgevers is het heel aanlokkelijk om overwerken te stimuleren of eenvoudigweg toe te staan. Let wel dat dit gedrag op den duur een negatieve secundaire arbeidsvoorwaarde vormt. Beloon medewerkers dus niet voor overwerk, verwacht in tegenstelling dat ze het werk doen in de tijd die er voor staat.

Denk er aan dat medewerkers een thuisfront hebben die het overwerken gegarandeerd niet zullen waarderen. Ook al is vrijwillig overwerken een eigen verantwoording van de medewerker, het kan op termijn tot problemen leiden die toch op het bordje van de ondernemer komen. Steek niet je kop in het zand, bespreek wat je ziet en geef aan hoe je er in staat.

Een medewerker die overwerkt, is geen reden tot feest, maar reden tot zorg. Er van uit gaande dat een medewerker naast het werk een leuk leven heeft (iets wat je iedereen gunt), is het logisch te concluderen dat hij overwerkt omdat hij te veel werk op zijn bordje heeft. Als je je werk niet tijdig af krijgt, is meer werken nooit de oplossing. Zoek de oplossing eerder in een betere organisatie van het werk. Ziezo! Die reden voor overwerk is ook onder tafel geveegd.

Deze productiviteits-waarschuwing geldt ook voor ondernemers. Of wellicht juist voor ondernemers. Structureel veel werken is geen oplossing om al het werk gedaan te krijgen. Een ondernemer die 70 uur per week werk, doet er goed aan een extra medewerker aan te nemen en cursus organiseren en delegeren te volgen. Er zijn leukere dingen dan op kantoor zitten (tip: pak eens een terrasje of doe eens iets leuks met je kinderen).

De oplossing voor dit hete hangijzer is eigenlijk heel simpel: de prikklok. Werken volgens de prikklok is het meest eerlijke wat je kunt bedenken. Medewerkers krijgen zo iedere minuut uitbetaald. Letterlijk loon naar werken. Helaas kleven aan deze oplossing nogal wat negatieve associaties en past hij niet in het nieuwe mobiele werken. Jammer, maar het was ook eigenlijk te mooi om waar te zijn.

Vliegtuigongeluk bij Ueberlingen

Samenvatting

Het ongeluk bij Ueberlingen op 1 juli 2002 is het tragische resultaat van een ongelukkige samenloop van omstandigheden waarbij 71 mensen om het leven kwamen. Het is een ongeluk waarbij de technologie werkte zoals bedoeld, en de mens de zwakste schakel bleek. De gemaakte mensenlijke fouten zijn stuk voor stuk wellicht voorstelbaar, maar leiden desondanks tot de desastreuze gevolgen. Om deze reden dienen uit dit ongeluk lessen getrokken te worden waarmee een nieuw soortgelijk ongeluk kan worden voorkomen.

Inleiding

Op 1 juli 2002 zijn twee vliegtuigen op elkaar gebotst. Bij het ongeval kwamen 71 mensen om het leven, voornamelijk schoolkinderen. Het incident vond ‘s avonds laat plaats in de buurt van de Zuid-Duitse plaats Ueberlingen. Een Tupolev was onderweg van Moskou naar Barcelona, een Boeing van Bergamo naar Brussel. Hoe hebben twee vliegtuigen tijdens een heldere nacht zonder druk vliegverkeer elkaar zo exact kunnen raken? Op het eerste gezicht lijkt dit een freak-accident. Nadere analyse brengt feiten aan het licht waar lering uit getrokken kan worden. Dat deze lessen nodig zijn blijkt uit het feit dat een jaar eerder een soortgelijke situatie heeft plaatsgevonden, waarbij meer dan 700 mensen betrokken waren.

Analyse van de gebeurtenissen

De twee vliegtuigen vlogen op dezelfde hoogte en hadden een koers en snelheid waarbij het onvermijdelijk was dat ze elkaar zouden raken. De beide vliegtuigen waren echter uitgerust met een TCAS. Dit is een apparaat aan boord van een vliegtuig dat andere vliegtuigen in de buurt kan detecteren en zodoende botsingen kan voorspellen. Wanneer de TCAS een botsing ziet aankomen, zal het de bemanning van beide vliegtuigen een advies geven en zo een daadwerkelijke botsing voorkomen. Het ene vliegtuig krijgt het advies te stijgen (in dit geval de Tupolev), het andere om te dalen (de Boeing).

Het apparaat functioneerde in beide vliegtuigen goed. De goed werkende techniek heeft desondanks dit ongeval niet kunnen voorkomen. Zoals vele ongelukken was ook dit ongeluk een samenloop van omstandigheden. De Boeing volgende het advies van de TCAS om te dalen. De Tupolev daalde tegelijktertijd ook. Niet op advies van de TCAS, die adviseerde te stijgen, maar op advies van de luchtverkeersleiding. De luchtverkeersleiding gaf dit advies zonder te weten dat de TCAS adviseerde te stijgen. Al is het cru, men kan stellen dat zonder tussenkomst van de luchtverkeersleiding het ongeluk niet zou hebben plaatsgevonden.

Het is duidelijk dat zowel de luchtverkeersleiding als de bemanning van de beide vliegtuigen geen compleet overzicht hadden van de situatie. De enige die wel een botsing zag aankomen was de algehele luchtverkeersleiding in Karlsruhe. Deze probeerde contact te leggen met de lokale luchtverkeersleiding in Zurich, maar kon wegens problemen met de telefoon geen contact krijgen.

De lokale luchtverkeersleiding in Zurich was op het moment van het ongeluk bemand door slechts één persoon. Dit was een langstaande traditie binnen het luchtverkeersleidingscentrum. De tweede persoon had pauze en bevond zich enkele kamers verderop. De persoon die dienst had, had juist een vliegtuiglanding begeleid. Voor deze landing had hij zowel zijn eigen scherm, als het scherm van zijn collega nodig. Hij kon beide schermen alleen overzien door met zijn burostoel tussen beide scherm heen-en-weer te rijden. Het begeleiden van de landing en het heen-en-weer pendelen tussen twee schermen vormde een afleiding voor de luchtverkeersleider.

Wellicht even tragisch als het ongeluk zelf is de gebeurtenis van een jaar later. De luchtverkeersleider die tijdens het ongeluk in Zurich dienst had is door messteken vermoord. Of er een rechtstreeks verband is met het ongeluk is niet met 100% zekerheid te zeggen. Het is wel duidelijk dat een vliegtuigongeluk een beladen onderwerp is waarbij de emoties hoog oplopen, zowel op persoonlijk, economisch als op politiek nivo. Er wordt snel gezocht naar één schuldige terwijl iedereen in de hele vliegtuigindustrie een aandeel heeft in de veiligheid van alle betrokkenen.

Aanbevelingen

  • Piloten dienen het advies van de TCAS te volgen, ook als ze een tegenstrijdig advies krijgen van de luchtverkeersleiding. Zij dienen dit tegenstrijdige advies te melden aan de luchtverkeersleiding.
  • De luchtverkeersleiding dient altijd door minimaal twee personen bemand te worden.
  • De werksituatie in Zurich dient aangepast te worden zodat luchtverkeersleiders makkelijker op elkaars schermen kunnen kijken.
  • Ongelukken dienen onpartijdig onderzocht te worden en tijdens rapportages dient naar alle partijen, van nabestaanden tot vliegtuigbouwers, duidelijk te worden gemaakt dat er vrijwel nooit één schuldige valt aan te wijzen.

Metaforen in de user-interface (deel 3)

Dat metaforen nut hebben wordt ondersteund door de studie van Hsu et al (Hsu, 2002). Zij lieten proefpersonen zoeken in een grote tekst die middels drie verschillende user-interfaces doorzoekbaar was. In de eerste interface kon alleen via hyperlinks van artikel naar artikel worden genavigeerd. De tweede interface was daarnaast opgebouwd als boek en via de inhoudsopgave doorzoekbaar. De derde interface ondersteunde ook het zoeken via een folder systeem waarbij de hoofdstukken als tabbladen zichtbaar waren. Des te meer metaforen werden gebruikt, des te sneller en beter konden de proefpersonen, op de tekst betrekking hebbende, vragen beantwoorden.

Uit het voorbeeld van de orientatiemetafoor blijkt dat bij het gebruik van metaforen sterk rekening moet worden gehouden met cultuurverschillen. In oosterse culturen wordt van rechts naar links gelezen waardoor de metafoor rechts is verder geen (of minder) betekenis heeft (Barr, 2005). In het algemeen kan gesteld worden dat metaforen afgestemd dienen te worden op het kennisnivo van de gebruiker. Wanneer de gebruiker niet bekend is het brondomein, dan heeft de metafoor geen nut.

Hetzelfde kan gesteld worden wanneer de mapping van bron- naar doeldomein niet aansluit (Erickson, 1990). Wanneer een metafoor in het doeldomein niet volledig wordt gebruikt, dan kan dit verwachtingen scheppen die bij de gebruiker niet worden ingevuld. Zo kan een bestand wel in een map geplaatst worden, maar een map kan niet in een archiefkast. Ook kunnen in een computer mappen een eindeloze hiërarchie vormen. Deze mismatch tussen bron- en doeldomein kan bij gebruikers veel verwarring schepping waardoor het gebruik van de metafoor wordt ontkracht.

Erickson geeft een aantal concrete aanbeveling ten aanzien van het gebruik van metaforen (Erickson, 1990):

  • Een metafoor moet structuur en houvast geven aan de gebruiker. Des te concreter het brondomein is, des te beter.
  • Het brondomein moet bekend zijn bij de gebruiker. Des te meer de gebruiker weet over het brondomein, des te levendiger beeld hij zich kan vormen.
  • Het brondomein moet relevant zijn en nauw aansluiten op het doeldomein.
  • Het gebruik van de metafoor moet in de toekomst uitbreidbaar zijn. Wanneer nieuwe functionaliteit in de software beschikbaar komt, dan moet de aanpassing in de user-interface voort kunnen bouwen op de eerder gekozen metafoor.

Literaatuurlijst

Barr, P, Biddle R & Noble J (2005), A taxonomy of user-interface metaphors

Erickson T.D. (1990), Working with interface metaphors

Hsu, Y & Schwen, T. M (2002). The effects of structural cues from multiple metaphors on computer user’s information search performance

Metaforen in de user-interface (deel 2)

Metaforen zijn in te delen in een taxonomy. Deze bestaat uit orientatiemetaforen, ontologische metaforen, structuurmetaforen en metonymische metaforen (Barr, 2005).

Een orientatiemetafoor maakt onder andere gebruik van richting om betekenis te geven. Zo is in de westerse cultuur de betekenis van rechts: verder of volgende. Van deze metafoor kan gebruik gemaakt worden door in een user-interface een pijltje naar rechts te gebruiken om naar een volgende pagina te navigeren. Een pijltje naar links betekend terug en naar boven betekend naar een bovenliggend nivo.

Een ontologische metafoor gebruikt een concreet object om iets abstracts te duiden. In het volgende fragment wordt tijd als object gebruikt: “Ik heb niet genoeg tijd.” Ontologische metaforen zijn in eerste instantie lastig voor te stellen in een user-interface. Tegelijkertijd zijn ze overal. Denk hierbij aan fouten die iets kunnen veroorzaken. Let wel dat de fout een voor de gebruiker abstract concept is, terwijl dit voor de programmeur niet abstract hoeft te zijn.

Structuurmetaforen helpen bijvoorbeeld om het werken met data eenvoudiger te maken. Data wordt in de user-interface getoond als bestanden, die in mappen kunnen worden geplaatst. Een bestand en een map zijn elementen, het verplaatsen is een proces. De gebruiker denkt hierdoor in bekende termen en hoeft niet te begrijpen wat er daadwerkelijk in de computer gebeurt.

Wanneer in een user-interface een kleine foto van een persoon wordt getoond om de gehele persoon aan te duiden, dan is sprake van een metonymy. Bij een metonymy wordt een deel van iets gebruikt om iets groters aan te duiden. Dit hoeft geen concreet element te zijn, maar kan ook verwijzen naar een proces. Een voorbeeld hiervan is het gebruik van icoontjes waarmee een actie kan worden gestart. Het icoontje stelt de actie voor.

Literaatuurlijst

Barr, P, Biddle R & Noble J (2005), A taxonomy of user-interface metaphors

Erickson T.D. (1990), Working with interface metaphors

Hsu, Y & Schwen, T. M (2002). The effects of structural cues from multiple metaphors on computer user’s information search performance

Metaforen in de user-interface (deel 1)

Bij het ontwerpen van user-interfaces wordt al sinds de jaren 80 gebruik gemaakt van metaforen (Hsu et al, 2002). In het dagelijks leven gebruiken we iedere dag metaforen, los van de computer en user-interfaces. Metaforen zijn een integraal deel van ons leven, terwijl we dat vaak niet beseffen (Erickson, 1990). Ter illustratie geven Lakoff en Johnson in hun boek, Methaphors We Live By, een beschrijving hoe een discussie kan worden beschreven in termen van oorlog (in: Erickson, 1990). Een discussie heeft partijen die hun posities verdedigen en zwakke stellingen van de andere partij aanvallen. Door een discussie in termen van oorlog te beschrijven wordt het duidelijker wat een discussie is. Bij de concrete term oorlog kunnen mensen zich een beter beeld vormen dan bij de abstracte term discussie.

Een metafoor wordt gebruikt om iets wat nieuw of abstract is te begrijpen door termen te gebruiken uit een geheel ander domein. Een domein wat wel bekend of concreet is. Een metafoor heeft daarmee twee componenten: het brondomein en het doeldomein (Barr, 2005). Het brondomein is het bekende (in het vorige voorbeeld de oorlog). Het doeldomein is het domein waarop het brondomein wordt toegepast (de discussie). Het doeldomein wordt beschreven in termen van het brondomein.

Literaatuurlijst

Barr, P, Biddle R & Noble J (2005), A taxonomy of user-interface metaphors

Erickson T.D. (1990), Working with interface metaphors

Hsu, Y & Schwen, T. M (2002). The effects of structural cues from multiple metaphors on computer user’s information search performance