Gemiddeld gezien lopen software-projecten uit, staan ontwikkelaars onder druk en raken projectleiders gestresst. Deze optelling is niet goed voor de mensen, niet goed voor de kwaliteit en uiteindelijk niet goed voor de portomonee. Een aantal slimme koppen kwamen bij elkaar en schreef in het Agile manifesto dat de software-productie een ‘sustainable pace’ dient te hebben. Het tempo binnen een project moet vol te houden zijn. Makkelijk gezegd, maar hoe kom je tot zo’n houdbaar tempo? Vorige week hebben we binnen Octavalent opnieuw al het geplande werk afgekregen. Wat betekent dat en hoe doen we dat?

Iedere maandagochtend houden we de zogenaamde weekopening. In deze vergadering, waarbij iedereen aanwezig is, bespreken we de voorgaande week en plannen we het werk voor de komende week. Dit geplande werk is niet zo maar een gedachte, maar zien we als een commitment. Hoe gaat dit plannen in zijn werk?

Een software-project hakken we op in zo klein mogelijk stukken: de stories. Uiteindelijk bestaat een groot project daardoor uit enkele tientallen handzame stories. Iedere story kennen we een aantal punten toe. 1 punt betekent dat het niet veel werk is, niet complex is, en niet veel risico behelst. 2 punten betekent letterlijk 2 keer zoveel als 1, en 8 punten betekent dus 4 keer zoveel als 2 punten. Door punten te gebruiken in plaats van uren (en dit te schatten middels planningpoker) blijkt het aantal punten redelijke goed te kloppen.

Door stories in te plannen in een week, kun je de punten bij elkaar optellen en zo komen tot een totaal aantal punten voor die week. Achteraf kun je tellen hoeveel punten je daadwerkelijk gedaan hebt. Door dit een lange periode vol te houden (en hier zit de crux), bouwden we ervaringsstatistieken op. Zo weten we dat we gemiddeld 9 punten per FTE kunnen doen. Nu wordt het al gemakkelijker.

Tel op maandag de beschikbaarheid van de ontwikkelaars (in FTE), vermenigvuldig dit met 9 en dan hebben we het aantal punten dat we de komende week inplannen. Aangezien de stories punten kregen vóór het maken van deze rekensom, is het daarná slechts een kwestie van bepalen welke stories in de komende week op het planbord komen.

So far, so good. Maar we zijn er niet. Niets garandeerd dat de week niet overhoop wordt gehaald door haastklussen, bugmeldingen en tegenvallers. Haastklussen zijn heel simpel. Dat kan altijd, maar moet geruild worden met eerder ingepland werk. Dit is het principe van: “Je wilt dat XYZ in de planning komt? Wat gaat er dan uit de planning?”.

Bugmeldingen zijn lastiger. Een plotselinge test-woede van een collega of klant kan een stortvloed van kleine verbeterpunten opleveren. Alles is even belangrijk, maar het is de vraag of het nu moet. Bugs die geen showstoppers zijn, stellen we zonder pardon uit tot de volgende week. Blijkt op die maandag dat er veel bugs opgelost moeten worden, dan stellen we de productiviteits-schatting navenant bij van 9 naar 8 (of 7 of 6). Zijn er weinig bugs, dan gaat de productiviteits-schatting naar 10, of wellicht 11. Door bugs niet direct op te pakken, maar in te plannen, creeëren we een hoop rust wat de kwaliteit ten goede komt.

Tot slot kan het werk altijd tegenvallen. Een 2-punter (statistische gezien 6 uur werk) kan 3 dagen in beslag nemen. Weg planning? Niet helemaal. We hebben nog een sluitpost. Die sluitpost heet ‘Verbeteringen’. Verbetering zijn werkzaamheden waarvan het ontwikkelteam vindt dat ze nodig zijn. Voorbeelden zijn: wijzigingen in de architectuur, het inzetten van een nieuw technologie of het upgraden van een component. Dit zijn werkzaamheden die niet onmiddelijk moeten gebeuren. Ze kunnen makkelijk worden uitgesteld naar de volgende week. En dat doen we dan ook.

Hier zit wel een valkuil. Door verbeteringen als sluitpost te hanteren, loop je het risico er nooit aan toe te komen. Wij hebben dit ondervangen door voor verbeteringen een budget te bepalen, en wel 10% van alle ontwikkeluren. Dit tellen we per kwartaal. Stel dat we na drie weken in het kwartaal slechts 5% hebben besteed aan verbeteringen, dan weten we dus dat we voor de volgende week een lagere productiviteit moeten aanhouden.

Bij Octavalent zijn we op zoek naar een nieuwe ontwikkelaar. Ik krijg daarom weer veel CV’s onder ogen. Sommigen zijn goed, anderen vallen tegen. Het CV van een software-ontwikkelaar is net iets anders dan een gemiddeld CV. Vooral het kopje opleiding en ervaring met bepaalde technologieën. Wat zoek ik precies in een CV?

Algemeen

Gebruik niet te veel tekst. Opsommingen zijn super. Ook de standaard opmaak van een leeg Microsoft Word document voldoet prima. Schrijf maximaal twee kantjes en motiveer in je e-mail waarom je juist voor deze functie, bij dit bedrijf solliciteert.

Personalia

Hier staat puur feitelijke informatie over wie je bent, hoe je te bereiken bent en waar ik op internet meer over je kan vinden. Toon: naam, geboortedatum, adres, telefoonnummer, email en eventuele websites (zoals linkedin, weblog, github- of stackoverflow-pagina). Wees niet de benauwd om een foto bij te voegen. Het gaat er om dat ik je kan herinneren en een foto helpt.

Opleiding

Beschrijf alle opleidingen, cursussen, en trainingen die je gedaan hebt. Let er wel op dat opleidingen minder relevant zijn dan vroeger. Kennis is vluchtiger, dus een training van vier jaar geleden voegt niet veel meer toe. Ook zijn er veel meer mogelijkheden om bij te blijven. Lees je actief weblogs? Luister je podcasts? Zet dit dan bij opleidingen. Bij opleidingen wil ik zien waar je je basiskennis vandaan hebt (HBO/WO), en hoe je op de hoogte blijft van nieuwe ontwikkelingen.

Ik ben altijd een beetje beducht op (oud-)medewerkers van een detacheringsbureau die in wel heel veel opleidingen hebben gedaan. Dit wijst er meestal op dat ze op de ‘bank’ zaten/zitten. Goede medewerkers zitten namelijk op een project en doen alleen certificerings-trajecten als het echt moet.

Werkervaring

Werkervaring is meer dan een lijst met bedrijven waar iemand werkte. Sterker, de bedrijven boeien mij niet zo. Ik ken ze toch niet. Ik ben meer geïnteresseerd in de projecten waar iemand aan werkte: voor welke klant, hoelang, in welke rol en met welke technologieën. Dat gezegd hebbende wil ik wel weten hoelang iemand gemiddeld bij een werkgever werkt. Toon dus werkgevers, en per werkgever de projecten.

Veel werkervaring is goed, veel verschillende ervaringen is minder goed. Ik zoek iemand die focus heeft op een bepaalde technologie en binnen die technologie weet waar hij het over heeft. Een jack-of-all-trades kan over veel meepraten, maar is nergens echt goed in. Dit heeft zo zijn waarde, maar ik zoek het niet. Toon in je werkervaring welke technologieën, frameworks, talen, en bibliotheken je gebruikt hebt. Of je aan veel of weinig projecten hebt gewerkt is niet zo relevant. Als er maar een lijn in zit.

Zeg niet te snel dat je een expert bent in taal XYZ. Toon het mij. Bijvoorbeeld door er een aantal jaren mee gewerkt te hebben. Iemand die na twee jaar claimt C# -expert te zijn is voor mij niet geloofwaardig, en ondermijnt zijn CV. In tegenstelling: wanneer iemand vier jaar ervaring heeft met C#, dan trek ik zelf wel de conclusie dat hij weet waar hij mee bezig is.

Overigen

Iedere medewerker brengt niet alleen zijn hoofd en handen in, maar ook iets extra’s. Dit extra’s is met name in een kleinere organisatie van belang. Dat je op voetbal zit is niet zo relevant, wel als je daar iets speciaals doet: bijvoorbeeld door in de feest-commissie te zitten of voetbaltraining te geven. Spreek je vloeiend een vreemde talen die handig kan zijn? Ben je BHV-er? Heb je gewerkt aan een open-source project? Help je ouderen met het wegwijs worden op de computer? Schrijf je een blog? Doe je vrijwilligerswerk? Schrijf het hier op.

Struinend in mijn (ongepubliceerd) archief kwam ik de specificaties tegen voor een spelletjeswebsite. Ik meen mij te herinneren dat ik deze ooit schreef voor een wedstrijd. Later bleek dat de wedstrijd bedoeld was voor studenten en dat de inschrijving al was gesloten. Zo raakten het idee in de vergetelheid tot ik de tekst zojuist weer tegen kwam. Ik las hem en vond het nog steeds een aardige vonst.

Hierbij het concept: De website biedt puzzels aan. Een puzzel is een raadsel waarbij de bezoeker aan de hand van een hint een locatie moet raden. Dit kan een locatie zijn overal ter wereld. De puzzelaar ziet op het scherm een wereldkaart en hij moet op de kaart de juiste locatie aanklikken. Klikt hij inderdaad juist, dan heeft hij de puzzel gewonnen. Iedere puzzelaar kan zelf puzzels maken. Een puzzel bestaat uit uit de eerder genoemde hint & locatie (latitude en longitude) en een radius. De locatie in combinatie met de radius vormt een cirkel op aarde.

Om de juiste locatie te kunnen raden heeft de puzzelaar twee hulpmiddelen. Allereerst is er de hint. Het tweede hulpmiddel is het commentaar van andere puzzelaars. Je speelt een puzzel namelijk nooit alleen, iedereen kan met dezelfde puzzel meespelen. Als puzzelaar kun je suggestie aan een puzzel toevoegen. Op deze manier speel je tegelijkertijd met elkaar, maar ook tegen elkaar. Suggesties van anderen helpen jou, maar jouw suggesties helpen anderen.

Bij een goed spel valt iets te winnen, zo ook hier: punten. Bij het geven van suggesties kan de bedenker van de puzzel jouw suggesties upvoten en downvoten. Upvoten levert je 10 punten op, downvoten kost je 2 punten. Het totaal aantal punten van de upvotes en downvotes bepaalt de waarde van een puzzel. Win je de puzzel dan krijg je de waarde van de puzzel toegevoegd aan jouw totaal. Hetzelfde geldt voor de bedenker van de puzzel, die krijgt ook dat aantal punten. Je kunt dus op drie manieren punten scoren: door goede suggesties te leveren, door een puzzel te winnen en door een puzzel te verzinnen.

“Patentterreur verjaagt app-makers uit ‘gevaarlijk’ VS” kopte een artikel op de technologie-website Webwereld. Het was een artikel waar ik al een tijdje op zat te wachten. En ik werd er niet blij van. Kun je als Nederlands (of Europees) technologiebedrijf met een software-product mondiaal succes hebben? Met de patentoorlog die gaande is wordt het in ieder geval niet gemakkelijker.

Nederlandse software-makers zijn altijd al huiverig geweest voor verkoop in Amerika. De angst voor torenhoge claims is groot. Geen idee of dit volledig terecht is, maar ik kan mij er iets bij voorstellen. Amerika heeft nu eenmaal de reputatie dat klanten (of zelfs wildvreemden) je voor de raarste dingen voor het gerecht slepen. Vroeger hoefde je praktisch alleen maar bang te zijn dat anderen schade opliepen bij gebruik van jouw producten. En als jouw product goed in elkaar zat, dan waren de risico’s beperkt. De patentoorlog heeft hier een nieuwe dimensie aan toegevoegd.

Software-ontwikkelaars zijn over het algemeen creatieve mensen die features bedenken waar je bij staat. Stop een stel software-savvy mensen in een hok en de ideeën stromen over. Tot de patent-oorlog uitbrak was het een kwestie van prioriteren en bouwen maar. Tegenwoordig moet je rekening houden met patenten. Stel dat je een goed idee hebt voor een nieuwe feature, dan is de kans groot dat jij niet de enige bent met dit ‘briljante’ idee. En als iemand in Amerika dat idee ook had en hij werkt bij een groot bedrijf, dan is de kans groot dat het idee gepatenteerd is.

Maar wat betekent een software-patent eigenlijk? Kort gezegd komt het er op neer dat als je gepatenteerde technologie in jouw software gebruikt, dat je moet betalen aan de patenthouder. Ook als je ten tijde van de software-ontwikkeling niet wist dat er een patent was. Tijdens het ontwikkelen van software kun je dus ongemerkt inbreuk maken op patenten van anderen. Aan het proces van software ontwikkelen is door de patent-oorlog een extra activiteit toegevoegd: onderzoek doen naar patenten en nieuwe patenten aanvragen.

Nu gelden de patenten strikt gezien alleen voor Amerika. In Nederland (en geheel Europa) is het niet mogelijk om patenten op software aan te vragen. Software wordt gezien als algoritmes, wiskundige formules dus. En uitvindingen in de wiskunde kun je in Europa niet patenteren. Is er dus wel een probleem?

De Amerikaanse markt wordt gevormd door de patentoorlog. Amerikaanse softwarebedrijven houden bij de ontwikkeling van software rekening met patenten. Ze gebruiken geen gepatenteerde ideeën of patenteren zelf defensief. Amerikaanse bedrijven groeien op in een ecosysteem waarin patenteren een normaal onderdeel van het leven is. Europese bedrijven komen tot wasdom in een ander model. Omdat zij nooit rekening hoefden te houden met patenten, maken zij ongemerkt inbreuk op allerlei Amerikaanse patenten. Dit is geen enkel probleem, totdat ze de Amerikaanse markt op gaan. Het ‘niet gewend zijn aan patenten’ is een barrière voor toegang tot de Amerikaanse markt.

Op zich is Europa voor een Nederlandse bedrijf groot genoeg. Er zijn groeimogelijkheden zat op ons continent. Er is echter een bepaald type markt waarbij Amerika een must is: de winnner-takes-all-markt. Dit is een markt waarbij één of twee grote spelers (uiteindelijk) domineren. Enkele voorbeelden zijn: zoekmachines (Google, Yahoo, MSN), en sociale netwerken (FaceBook, LinkedIn). In een markt waarbij Europeanen niet naar Amerika kunnen, maar Amerikanen wel naar ons, delven wij per definitie het onderspit.

Er is echter een positieve kant aan de patent-woede. Tegenstanders van (software)patenten claimen dat patenten innovatie in de weg staan. In een systeem van gesloten innovatie kun je niet bij elkaar in de keuken kijken en geen gebruik maken van uitvindingen en ideeën van anderen. Europese bedrijven zijn door de koers van open innovatie wellicht in het voordeel. Hoewel hier ook het principe geldt dat Amerikanen wel in onze keuken kunnen kijken, maar wij niet in die van hen.

We zullen het zien.