Veel bedrijven selecteren softwareframeworks en rad-platformen (rapid application delivery) op basis van een hackathon. Een aantal geselecteerde partijen krijgt opdracht om bij de klant op kantoor een bepaalde oplossing te bouwen en na afloop beoordeelt de klant wie het het beste heeft gedaan. De winnaar krijgt de opdracht. Eerlijk? Nou… meestal niet!
Laatst was ik weer eens aanwezig bij zo’n hackathon. Een partner van ons ging onze software gebruiken en ik wilde met eigen ogen zien hoe het eraan toeging. Zo’n hackathon voelt een beetje als een wedstrijd en is daardoor vaak spannend. De deelnemers krijgen de opdracht pas vlak van tevoren en kunnen zich dus niet voorbereiden. En daarbij staat er nogal wat op het spel: degene die wint, krijgt de opdracht.
X functionaliteit
Toch zit er een groot nadeel aan het werken met zo’n hackathon: applicaties worden maar op een klein deel van de gestelde eisen bekeken. Meestal luidt de opdracht: ‘bouw binnen de tijd een applicatie met x functionaliteit.’ Er wordt, met andere woorden, alleen gekeken naar bouwsnelheid en functionaliteit, maar bijvoorbeeld niet naar de beheerbaarheid en flexibiliteit van de gebouwde apps.
Is de gebouwde app makkelijk aan te passen? Is de app makkelijk te integreren met andere software? Iets nieuws bouwen is simpel. Veel lastiger is het om een verandering in bestaande software door te voeren en deze te laten landen in het huidige applicatielandschap.
Backlogs
Ik kwam ook in gesprek met de partij die de hackathon had uitgeschreven. Hij vertelde mij dat hij tevreden was met de gestelde parameters: productie van code, logica en modules. En dat is iets wat ik helaas veel vaker zie. It-afdelingen hebben te maken met druk uit de business om applicaties snel te bouwen en op te leveren en gaan daarom op zoek naar een rad-platform of een nieuw software framework. Ze gaan dan echter voorbij aan het eigenlijke probleem: het beheer van de applicaties. Het kost de it-afdeling steeds meer tijd om bestaande applicaties aan te passen en te wijzigen. It krijgt hierdoor een backlog en kan daardoor niet meer goed de verzoeken van de business behandelen.
Als je alleen maar kijkt naar de snelheid van codekloppen, kijk je uiteindelijk maar naar één aspect van de software-tooling. Je gaat dan geheid een kat in de zak kopen. Als je een nieuw huis koopt, ga je toch ook niet alleen maar af op de inrichting? Je onderzoekt toch ook de fundering? En je vraagt toch ook een bouwkundig rapport op?
Change
De oplossing is mijns inziens eenvoudig: stel een businessprobleem centraal tijdens een hackathon, niet een it-probleem. Door het businessprobleem te schetsen, geef je de programmeurs de mogelijkheid creatief te zijn bij het vinden van een oplossing. Zaken als ‘integratie met andere systemen’ ga je dan beter testen. En een tweede punt is ook cruciaal: geef halverwege de wedstrijd opdracht om de applicatie te wijzigen. Dat gebeurt in het echt ook. Waarom dan eigenlijk niet tijdens zo’n hackathon?
Ik denk dat als je deze parameters op die manier aanpast, je tot betere beslissingen gaat komen. En niet onbelangrijk: het wordt er ook leuker door! Halverwege de wedstrijd een change request maakt het een stuk dynamischer en vooral ook realistischer. En dat is wat je wilt als opdrachtgever. De mogelijkheden en onmogelijkheden van een platform boven tafel krijgen in een zo realistisch mogelijke setting.
Om maar direct op uw voorgestelde oplossing te reageren:
Een hackathon is al gauw een technische aangelegenheid, omdat er in een korte periode iets ‘in elkaar gehackt moet worden’. Ideaal om snel even te laten zien of iets wel gerealiseerd kan worden (voor bijvoorbeeld een POC), om het later nog eens netjes overnieuw te doen. Een businessprobleem schetsen zou er al voor zorgen dat er meer tijd voor nodig is om tot een resultaat te komen, omdat er een vertaling moet plaatsvinden van business naar IT (met daarbij behorende berg aan informatie die verwerkt moet worden).
Een wijziging introduceren gedurende de hackathon wil uiteindelijk nog steeds niet garanderen dat het beoogde framework in de toekomst voldoende flexibel en beheerbaar is. Beheerbaarheid hangt bijvoorbeeld ook af van het feit of een technologie over 5 (of 10) jaar nog steeds gebruikt gaat worden of niet. Mocht het nodig zijn om kwaliteit van code te beoordelen (documentatie, stijl, etc.) is daar genoeg tooling voor beschikbaar om dit te doen (bijvoorbeeld SonarQube). Kwaliteit van code kan dan wel weer los staan van de gebruikte technologie, maar bijvoorbeeld de verdienste zijn van een kundige programmeur.
Een hackathon is, zoals u al aangeeft, niet geschikt voor het selecteren van een fundering voor een applicatie. Ik denk ook niet dat de door u beoogde oplossing ‘de oplossing’ is.
goed idee.
Meestal luidt de opdracht: ‘bouw binnen de tijd een applicatie met x functionaliteit.’
Das inderdaad maar duf en niet realistisch.
“De mogelijkheden en onmogelijkheden van een platform boven tafel krijgen in een zo realistisch mogelijke setting.”
Daar gaat het om lezen we in de laatste zin van het artikel
Hier heb je voorbeelden van eisen voor opdracht of changerequests.
– we willen graag standalone zonder internetconnectie hebben draaien.
– we willen hardwareoptimalisatie voor het door ons gekozen platform.
– we willen kunnen kiezen uit een groot aantal developers die die jaren ervaring
met de facto standaard programmeertaal hebben.
– we willen geen vendor lockin