DeveloperDerby 2006 programmeerwedstrijd

Februari 2006 –Whitehorses heeft voor de eerste keer in haar bestaan een eigen programmeerwedstrijd uitgevoerd, de DeveloperDerby 2006. In de DeveloperDerby hebben verschillende teams, ieder met een eigen technologiekeuze, geprobeerd in een korte tijd zoveel mogelijk functionaliteit van dezelfde business case te realiseren. Een verslag…

Doelstelling Whitehorses DeveloperDerby

Je hebt als ICT specialist tegenwoordig veel keuze als het gaat om frameworks en ontwikkeltools. Zelfs op Oracle en Java gebied zijn er legio mogelijkheden. Zoals dat hoort bij iedere betrokken ICT specialist leidt de keuze tot allerlei inhoudelijke discussies over de voordelen en nadelen. Er is echter maar één manier om het echt te weten te komen en dat is in de praktijk, of zoals de Engelsen zeggen: “The proof of the pudding in in the eating”.
De Whitehorses DeveloperDerby is een wedstrijd waarin een applicatie gebouwd wordt door verschillende teams met ieder een eigen technologiekeuze. De teams hebben evenveel tijd (twee dagen) en gebruiken dezelfde businesscase.

Het doel voor ieder team is een maximale score te bereiken voor functionaliteit en kwaliteit binnen dezelfde hoeveelheid tijd.

Omdat de uitgangspunten en de omstandigheden hetzelfde zijn (afgezien van de kennis en ervaring van de teamleden) zijn de resultaten van de teams goed vergelijkbaar. De opgedane kennis is bruikbaar bij keuzes voor technologieën in projecten. Ook kan de DeveloperDerby een goed ijkpunt zijn voor het huidige kennisniveau van de medewerkers.

Op persoonlijk vlak is de DeveloperDerby een goede gelegenheid om je collega’s te overtuigen van de ontwikkelkracht van jouw favoriete techniek!

Voorbereiding

Van tevoren is een businesscase gemaakt. Deze businesscase is geheim gehouden tot de dag van de Race zelf. Binnen de businesscase zijn allerlei te realiseren functionaliteiten benoemd. Voor iedere functionaliteit is hierbij benoemd hoeveel punten maximaal te verdienen zijn en wat de wenselijkheid van de functionaliteit is op basis van MOSCOW (Must have, Should have, Could have, Would have).

De jurering was van te voren benoemd. Deze bestond uit twee technisch specialisten (twee ex-werknemers!) en twee "gebruikers" (een directielid en ondergetekende).

De te gebruiken technieken waren vrij invulbaar binnen een keuzelijst. Na aanmelding van de collega’s ontstonden de volgende teams:

• Oracle ADF (met TopLink, Struts en ADF Faces)
• Oracle Designer (zonder CDM ruleframe)
• Oracle MOD PL/SQL (helaas uitgevallen wegens ziekte)
• Oracle HTML/DB
• Java Open Source (met AppFuse framework)

Een aantal team heeft hiermee een verassende keuze gemaakt. Alleen het Oracle Designer team bestond uit mensen met veel ervaring met de gekozen technologie. De andere teams hadden een dappere (en misschien overmoedige?) keuze gemaakt voor een techniek waarin zij weinig ervaring hadden.

De teams mochten hun eigen technische voorbereiding zelf invullen. Daarbij is verschillend te werk gegaan. Het Java Open Source team bestaande uit zeer ervaren Java specialisten heeft zich vooral “mentaal” voorbereid door de documentatie van een nieuw framework te lezen.

Het Oracle HTML/DB team heeft thuis geoefend met een eigen HTML/DB applicatie. Ook het ADF team heeft thuis geoefend op basis van een door Oracle gepubliceerd cookbook. Het Designer team had zich vooral voorbereid op de teamaspecten door het inventariseren van de beschikbare kennis en het verdelen van taken. Een voorbereiding op techniek was voor hun niet nodig.

Omdat het op voorhand al bekend was dat er sprake was van een verschillend ervaringsniveau (cq. ambitieniveau) en een verschillende omvang van de teams is er een handicap geïntroduceerd. Het uiteindelijk behaalde puntentotaal is daardoor gewogen op basis van de handicap.

Dag 1

Om half negen werd de businesscase uitgedeeld en vooraf waren al enkele databaseschema’s klaargezet met tabellen. Na uitleg gingen de teams van start. Gedurende de dag werd het verschil in aanpak zichtbaar. Het Java team kon nog geen scherm laten zien maar was wel vergevorderd in de “back-end” (lees: het framework) van de applicatie.

Het HTML/DB team kon het snelst wat schermen laten zien. De ene na de andere wizard flitste over het scherm. Pas in de middag kon een jurylid het team “betrappen” op daadwerkelijk coderen. Het Designer team was druk bezig met genereren van schermen en had al snel concrete resultaten. Het ADF team kwam snel tot zichtbare resultaten door ingebouwde ADF wizards maar moest enkele keren opnieuw beginnen door eerder gemaakte fouten. Een andere oplossing dan opnieuw beginnen was niet voorhanden met de beschikbare kennis.

Om 5 uur ’s middags werden de stekkers er uit getrokken en was het tijd voor een hapje en een drankje. Alleen het Designer team stond toen nog sterk in de schoenen. Het Java team zat op een dood spoor door problemen in het framework die niet oplosbaar leken. Het ADF team had nog te weinig functionaliteit gereed en het HTML/DB team was ook nog niet tevreden over de productiviteit.

Dag 2

Alleen de ochtend van de tweede dag was nog beschikbaar voor het verder afbouwen van de applicatie. In de middag kreeg ieder team een half uur de tijd om de eigen applicatie demonstreren en de jury te overtuigen. Ieder team had daar zo zijn eigen manier voor.

Het Designer team was vooral uit op het “afvinken” van functionaliteit. Al te veel vragen vanuit de kant van de jury werden niet gewaardeerd door het team. Er moest vooral tempo gemaakt worden met de demonstratie zodat alle functionaliteit beoordeeld kon worden. De jury kreeg een “lamme arm” van het invullen van de resultaten.

Het ADF team probeerde op “slinkse” wijze punten te scoren voor een niet werkend inlog scherm. De login leek goed te verlopen (ondanks het ontbreken van een wachtwoord verificatie!). Verderop gedurende de demonstratie maakte een concurrent de jury opmerkzaam op het feit dat het scherm niet overeenkwam met de inhoud van de database. Jammer maar helaas! Het team bestede ook vrij veel aandacht aan de gebruikte techniek en de hobbels op de weg. Dat was zeker interessant voor de toehoorder maar het was de jury niet duidelijk of dit een afleidingsmanoeuvre was om de geringe hoeveelheid functionaliteit te “verdoezelen” of dat het team zo enthousiast was over de technologie.

Het HTML/DB team gaf een gelikte presentatie. Je zou bijna zeggen dat je naar een Powerpoint presentatie zat te kijken. Het team bewees echter het tegendeel door nog tijdens de presentatie een nieuw stukje functionaliteit te bouwen. De jury was zo onder de indruk dat dit onderdeel toch nog heeft meegeteld voor het eindresultaat (ondanks de sluitingstermijn van 1 uur die middag).

Na de presentaties ging de jury aan de slag met het tellen van punten. Voor de teams een spannende tijd waarbij enige compensatie in de vorm van een biertje welkom was.

Eindresultaat

Niet verassend was het hoge scoringspercentage van het Designer team. Het is duidelijk dat Designer (nog steeds) een productieve tool is voor administratieve applicaties. Het team was ook geholpen met een businesscase van vooral administratieve aard. Toch heeft ook het Designer team lang niet alle functionaliteit kunnen bouwen. Het team heeft o.a. veel tijd verloren met het op gang krijgen van de Reports Server.

Verassend was de hoeveelheid gerealiseerde functionaliteit van het HTML/DB team. Zij hebben met weinig ervaring en 1 man minder dan het Designer team veel kunnen bereiken. Bovendien was de gerealiseerde applicatie gebruikersvriendelijker voor een (onervaren) gebruiker. Het blijkt dat met de “wizard” aanpak van HTML/DB snel veel functionaliteit ontwikkeld kan worden. De jury zet echter wel vraagtekens bij de aanpasbaarheid van de standaard userinterface van HTML/DB. Het aanpassen van de standaard templates van HTML/DB zal erg veel tijd vergen. HTML/DB lijkt daardoor geschikt voor applicaties die snel gerealiseerd moeten worden en waarbij weinig (extra) eisen worden gesteld aan de standaard userinterface en mogelijkheden van de tool.

Het Open Souce Java team heeft duidelijk een (te?) grote gok gewaagd door een geheel nieuwe technologie uit te proberen. De techniek was nog niet klaar voor een “confrontatie met de praktijk”. Volgende keer beter!

Het ADF team heeft zich voor het gevoel van de jury nog niet echt kunnen bewijzen. Het team heeft veel tijd verloren met het uitzoeken van verschillen tussen de eerder geprobeerde pre-productie release en de tijdens de DeveloperDerby gebruikte productierelease. Naar het oordeel van de jury heeft deze techniek echter de beste mix tussen productiviteit en flexibiliteit. Wij verwachten dan ook veel van dit team in de volgende Whitehorses DeveloperDerby!

De einduitslag

Conclusie

De Whitehorses DeveloperDerby 2006 was een daverend succes. Men was zeer te spreken over de organisatie en de begeleiding van de DeveloperDerby. Er is veel geleerd, we hebben veel gelachen.
Volgend jaar volgt zeker een herhaling. Wellicht dat er dan ook meer sprake is van evenwicht in de teams en gaat de strijd meer gelijk op.

Over de auteur
Martin van Borselaer is een principal consultant met meer dan 14 jaar ICT ervaring. Martin heeft in zijn loopbaan verantwoordelijke posities ingenomen in grote projecten bij overheidsinstanties en commerciële organisaties. Daarbij heeft hij verschillende functies bekleed in zowel de projectuitvoering (analyse, functioneel ontwerp, realisatie, architectuur) als projectaansturing (teamleider, projectleider en projectmanagement). De laatste 4 jaar heeft Martin zich vooral gericht op het gebied van business consultancy en veranderingsmanagement.