Verslag Developer Derby 2009

Februari 2009 - Voor al weer de 4e keer is bij Whitehorses de DeveloperDerby 2009 gehouden. Vijf teams van medewerkers van Whitehorses streden met elkaar voor de eeuwige eer en een gadget.

Iedereen verzamelde zich voor een kopje koffie en ontbijt en een gezellig samenzijn.

Klokslag 9 uur begon de presentatie van de case: Mustang - een administratieapplicatie waar leaseauto-berijders reisafstanden kunnen registreren, ten behoeve van de belastingdienst.

Mustang

Het fiscale klimaat voor leaseauto’s wordt steeds ongunstiger. Door de hoge bijtelling wordt het steeds interessanter voor leaserijders om de leasewagen uitsluitend zakelijk te rijden en privé een tweede auto voor de deur te zetten. Ook Whitehorses ziet deze trend onder haar medewerkers.

Om geen bijtelling te hoeven betalen, is het noodzakelijk om een kloppende rittenregistratie aan de belastingdienst te kunnen overleggen. Na het overleggen van een verklaring dat de auto niet privé gebruikt wordt, stopt Whitehorses met het maandelijks verrekenen van de bijtelling met het salaris.

Om de medewerkers van Whitehorses te ondersteunen, wordt jullie gevraagd om de applicatie Mustang te ontwikkelen waarin iedereen een rittenregistratie aan kan leggen, om het gebruik van de leaseauto inzichtelijk te houden.

Iedereen kreeg vervolgens op papier en per mail de case toegestuurd. De case was in Scrum-style: de eisen waaraan de applicatie moest voldoen waren als user-stories genoteerd, zoals user-story 3:

3 – Rit registreren

Als ingelogde medewerker wil ik ritten kunnen registreren bij de auto waarvan ik de sleutels heb. Zie de website voor de gegevens die de Belastingdienst per rit geregistreerd wil zien. Ik wil graag dat alle gegevens die al bekend kunnen zijn (zoals ritnummer, beginstand, vertrekpunt) al vooraf ingevuld zijn.

Mustang moet een waarschuwing geven als de invoer een "gat" in de registratie veroorzaakt (d.w.z. het geheel van begin- en eindstanden is niet sluitend, of vertrek/beginpunt van twee aansluitende ritten komen niet overeen).

Mustang moet eventuele ontbrekende gegevens zelf af kunnen leiden op basis van de gegevens die wél ingevuld zijn (bv. eindstand = beginstand + afstand, of afstand = eindstand – beginstand).

De tabelstructuur en ER-diagram waren al voorbereid en konden gebruikt worden als basis voor het programma:

Als eerste zouden de teams afgerekend worden op het aantal user-stories dat geïmplementeerd is volgens de genoemde eisen en de gebruikersvriendelijkheid van de applicatie. Daarnaast moet de architectuur en de source-code van de applicatie leesbaar en gestructureerd opgezet zijn. Tot slot, en dat was nieuw dit jaar, zou het team afgerekend worden op Whitehorses-waarde.

De puntentoewijzing op ‘inspelen op veranderingen’ kon gewonnen worden door het programma flexibel en aanpasbaar te ontwerpen. Halverwege de wedstrijd werd een nieuwe user-story geïntroduceerd. Het onderdeel kon behaald worden door de nieuwe user-story netjes en correct te implementeren.

De teams

Alle teams gingen met technieken aan de slag die volkomen nieuw waren voor enkele of alle leden. De teams en de technieken die zij gingen gebruiken:

Elk team kreeg een handicapscore, die democratisch bepaald werd door alle deelnemers. De handicap was een percentage welke het maximum bepaalde van de totaalscore die een team kon behalen. De handicap is ingevoerd, om teams die voor hen onbekende of vernieuwende technieken gebruiken, een voorsprong te geven.

Na uitdelen ging zocht iedereen een bureau op om aan de slag te gaan. Veel teams hadden een behoorlijk deel van de dag nodig om de eerste stappen van hun omgeving aan de gang te krijgen. De voorbereiding was vaak niet optimaal!

Elegante

Omdat het team Elegante (Italiaans voor Elegant), naar mening van de overige deelnemers, de meest onbekende en gedurfde stack gebruikte, kregen zij een handicap van 0%: ofwel zij konden als enige team de maximum score behalen.

Met Scala kon snel gewerkt worden, maar Flex bleek onderschat. Na een dag worstelen met Flex besloot Elegante om alsnog vertrouwde jsp’s/servlets in te zetten. Dat last-minute beslissing bracht het team op een behoorlijke achterstand.

Het lukte volgens hen wel een backend op te zetten met behulp van Scala. De frontend kon alleen niet waarmaken wat de backend zou moeten kunnen.

Bij hun presentatie gebruikte ze als enige geen Powerpoint, maar een whiteboard. De architectuur en werd kort uitgelegd, en niet onbelangrijk, een belangrijke les: blijf niet te lang hangen op een probleem.

Vervolgens demonstreerde ze hun versie van de rittenregistratie. De frontend van de applicatie, waar het uiteindelijk toch om draait, was zeer sober uitgewerkt. Bovendien gaf de last-minute verandering van technology-stack niet veel vertrouwen in de architectuur. Ze kregen uiteindelijk weinig punten toegekend.

TZN

Het team TZN, ‘Team zonder naam’, gebruikte -voor hen- behoorlijke bekende technieken. Daarom kregen ze een hoge handicap toebedeeld van 85%. Hoewel TZN bekende technieken gebruikte, hadden ze toch een behoorlijk langzame start. Een teamlid had een werkende stack opgezet met behulp van eigen DAO-classes.

Een van de leden wilde met JDeveloper DAO-classes genereren, want dat kon met JDeveloper heel makkelijk. De IDE van Oracle werkte echter niet mee.

Na enige uren worstelen konden ze echt aan de slag. Zij begonnen meteen met een strakke rolverdeling:

Een iemand was DBA’er en Scrum master. Hij coördineerde te implementeren functionaliteit en zorgde ervoor dat het database schema correct en up to date bleef.

Een ander team lid was verantwoordelijk voor de frontend in Flex. Als bedreven Flex-ontwikkelaar, programmeerde hij alles wat te maken had met weergave en gebruikersafhandeling.

Tot slot programmeerde een teamlid de backend met behulp van Java, Spring en BlazeDS.

Hun eindproduct zag er, door gebruik van Flex, zeer fraai en professioneel uit. Veel userstories waren geïmplementeerd en konden met succes gedemonstreerd worden. De presentatie was bescheiden opgezet – misschien iets te bescheiden.

Een aanmerking op hun architectuur was voor de Flex-gedeelte. Er werd geen gebruik gemaakt van een MVC-framework als Cairngorm, waardoor de code minder gestructureerd was als mogelijk is met Actionscript.

Hun team was behoorlijk gestroomlijnd, daarom kregen ze een hoge score toebedeeld op ‘Whitehorses’ waarden.

Beta blokkers

De beta blokkers noemde zich zo, omdat zij beta software van Oracle wilde gaan gebruiken: JHeadstart 11. Helaas voor de drie teamleden vond Oracle op de dag van de wedstrijd hun software nog net niet goed genoeg op gebruikt te worden buiten Oracle. Ze gingen daarom aan de slag met JHeadstart 10.

De meeste andere deelnemers meende dat ze die omgeving goed onder de knie moesten hebben – en waren behoorlijk overmoedig. Ze kregen daarom ook een hoge handicap van ‘85%’. Dat was onder protest van de Beta Blokkers: volgens hen hadden ze maar kort het product uitgeprobeerd voor de wedstrijd.

Desalniettemin konden ze na afloop van de wedstrijd een behoorlijke vergevorderd product demonstreren.

Door bugs in de programmatuur, traden bij demonstreren van veel user stories fouten op. Ook over de architectuur was de jury niet heel tevreden – er werd heel veel code gegenereerd. Hun product leek daardoor ook niet bijzonder flexibel. Dat de meeste deelnemers (voormalige) Java-programmeurs waren in plaats van PL/SQL speelde wellicht ook mee in een mindere score. Bovendien was, door beperkingen van JHeadstart 10, het uiterlijk van de applicatie niet fraai te noemen.

GT

Het team GT, ‘Groovy Team’ zou zijn naam en logo dan wel niet ontleend aan het racespel Gran Turismo, maar het ging als een geolied raceteam aan de slag. Een teamlid had zich gedegen voorbereiden in Groovy en Grails. Het andere teamlid had zich door werkdruk niet kunnen voorbereiden maar was ruim ervaren genoeg om de taal en het framework zich eigen te maken.

In korte tijden konden ze een groot aantal user stories uitprogrammeren. Bovendien bleek uit hun demonstratie het uiterlijk van het programma ook bijzonder fraai. Hun presentatie was enigszins rommelig. In de toegewezen tijd konden zij niet alles van hun applicatie demonstreren.

Wàt zij lieten zien zag er wel zeer fraai uit, bovendien functioneerde alles ook prima. Alles werkte snel, en zichtbare bugs traden niet op.

Totaal ontspoort

Het tweekoppige team Totaal Ontspoort bestond uit iemand die behoorlijk ervaren was in Ruby. De andere helft van het team was ervaren projectmanager, maar had vele jaren niet meer geprogrammeerd.

Aan het einde konden zij niet bijzonder veel geïmplementeerde userstories demonstreren. De presentatie was wel bijzonder humorvol, met opmerkingen als ‘het was bijna af’. Helaas voor hen, werden geen punten gegeven voor een eloquente presentatie.

De frontend in Flex was fraai opgezet, voor zover deze was afgerond. De backend, gebaseerd op Ruby en Ruboss was overtuigend.

Eindoordeel

Iedere deelnemer van elk team mocht de andere teams jureren – de gemiddelde publieksscore telde voor de helft.

De jury ging in beraad voor hun eindoordeel. Het GT team mocht alsnog extra onderdelen demonstreren vanwege hun overtuigend begin.

De eindscore werd als volgt:

Het GT team werd de overtuigende winnaar, zelfs als hun handicap meegeteld werd. De twee teamleden kregen naast eeuwige roem een handige gadget: een elektronische pen.