Je hoort het ons regelmatig zeggen: dat moeten we even met ‘de jongens’ bespreken. Daarmee doelen we op de heren developers die vanuit alle hoeken van het land (en zelfs vanaf Bali) de software op dagelijkse basis uitbreiden en beter maken. Graag stellen we je deze maand voor aan een van ‘de jongens’, namelijk lead developer Jurgen Bosch.
Voor onze eerste set aan programmeurs waren onze wensen veel te complex en kwamen we – gelukkig maar – met onze handen in ’t haar bij jou terecht. Onze reddende engel! Ik geloof zelfs dat je het eerder geprogrammeerde ‘weggegooid’ hebt en een gedegen nieuwe start hebt gemaakt. Hoe ging het ook alweer?
“Tja, dat is lang geleden.. Toen we begonnen was de organisatie echt nog jong, dus doe je alles lean & mean. Je weet nog niet precies welke code wel of niet belangrijk wordt, dus ga je redelijk kort door de bocht aan de slag met het idee daar later op doorontwikkelen op de onderdelen die steeds belangrijker worden in de software. Zo kan je eenvoudig mee in de ontwikkeling van de technieken, wat razendsnel gaat.
Inmiddels is Learning Heroes flink gegroeid en daarmee gepaard gaan een aantal belangrijke nieuwe concepten: modulair bouwen, automatisch testen, requirements nog gestructureerder bespreken en vastleggen.”
Dit is om futureproof te blijven, toch? Welke veranderingen kunnen we verwachten, en wat kan de klant daarvan merken?
“Het softwarepakket is vrij stabiel en reageert snel, ook bij veel bezoekers. De wijzigingen zijn dan ook vooral toekomstgericht. Als we nu bij de les blijven, behouden we die stabiliteit en snelheid.
Het softwarepakket is ook gigantisch gegroeid. Het team ook, dus ik kom steeds vaker code tegen die ik niet heb gebouwd of eerder heb gezien, dat is een extra laag complexiteit. Vergelijk het bijvoorbeeld met een spelletje memory: als je met drie setjes speelt, dan weet je prima waar alles ligt. Zeker als je ze zelf hebt neergelegd. Maar als je met elkaar duizend setjes legt en speelt en je vervangt 1 of 2 kaarten, dan heeft dat impact op het hele spel. Je ontkomt er niet aan om dan volgens een bepaalde systematiek te spelen. Hier zijn we momenteel mee bezig. Enerzijds met Domain Driven Design, anderzijds met automatisch testen.”
Domain Driven Design, wat moeten we ons daarbij voorstellen?
“Domain Driven Design is ontstaan uit de kloof tussen eindgebruikers en het development team. Als een bepaalde wens ontstaat bij de eindgebruiker van de software, moet dit eerst langs de business, vervolgens langs het product team om uiteindelijk bij het development team uit te komen. Op die reis worden verschillende vertaalslagen gemaakt, waarbij nuances en uitleg vaak verloren gaan. Daarbij snappen die verschillende disciplines elkaars taal niet. Software ontwikkelen is ook nog eens complex en leidt vaak tot onbegrip. Dit onbegrip komt vaak uit de vertaling van de wens naar de oplossing.
Bij Domain Driven Design begin je met alle disciplines bij elkaar en wordt de software ontworpen in de taal die de hele organisatie kent. We definiëren in Event Storming-sessies welke takken er in de organisatie zitten en vertalen dat naar domeinen.
Tijdens deze Event Storming-sessies bepalen we met het hele team welke dingen er kunnen gebeuren binnen dat domein en omschrijven deze events. Dit vormt de basis voor het programmeerwerk. Hierdoor weet iedereen in de keten wat er van de software verwacht kan worden en sluit de software veel beter aan bij de business. Daarnaast hebben we direct een goede documentatie van wat elk domein kan. Daarna schrijven de developers tests van het gewenste gedrag, het gewenst resultaat zeg maar en daarna pas de code. De code (software) moet er kort gezegd voor zorgen dat de test slaagt. Programmeren is zo nog maar de helft van het werk, de andere helft is het nadenken over en het uitwerken van wat precies nodig is.”
Dat klinkt goed, welke directe voordelen brengt dat mee voor onze klanten?
Het systeem wordt straks volledig modulair. Hierdoor is het mogelijk dat we domeinen vervangen voor ‘maatwerkdomeinen’, terwijl de rest van de code gelijk blijft aan het standaardpakket.
Event Storming heeft ons als voorbeeld ook veel inzicht gebracht over het management-gedeelte van de applicatie. Dit heeft ons ertoe gebracht dit gedeelte volledig nieuw te ontwerpen, waarbij we functioneel en design-technisch grote stappen gaan maken. De techniek is straks headless zoals we dat noemen; dat betekent dat we de front-end los hebben getrokken van de back-end en zo kan je als afnemer een volledig nieuw design laten maken voor de voorkant, terwijl dezelfde techniek in de achterkant gebruikt wordt. Alsof je thuis overal een lamp neer kan zetten en niet rekening hoeft te houden waar de eerste bewoner een stopcontact heeft geplaatst.
Daarnaast gaan we meer gebruikmaken van automatische tests. Als een softwarepakket groter wordt, wordt het steeds lastiger om het gehele pakket handmatig te testen. We gaan volledig over op automatisch testen zodat we een stabiel pakket kunnen blijven garanderen. Je hebt dan continu bereik over het hele memory spel. Dat is enorme winst.”
Dit proces doorloopt elke softwarepartij, toch?
Veel organisaties durven het niet aan om eens in de zoveel jaar de code volledig te vernieuwen. Vaak zie je dat er eindeloos wordt doorontwikkeld op het huidige product. Dat kan wel, maar het gaat op een gegeven moment knellen en dan ontstaan er problemen. Het is als spaghetti koken; in de verpakking alle sliertjes naast elkaar maar het eindresultaat op het bord is totaal anders. Dus elke nieuwe feature die je ontwikkelt, kost je dan evenveel tijd om te ontwikkelen als om de bugs te fixen die door deze nieuwe feature ontstaan. Je overziet namelijk niet meer waar wat zit.
Bij Learning Heroes gaan we die uitdaging wel aan. Ik vind het super dat Learning Heroes door deze pijn durft te gaat en dit traject aangaat. Het betekent nog een keer flink investeren zonder dat het zich direct terugverdient. Dat durven veel partijen niet, ik gok dat dit voor 90% van de partijen geldt. Met deze stap groeit niet alleen de software, maar het hele bedrijf en iedereen die erbij betrokken is.”
Maakt dat het werken bij Learning Heroes zo leuk?
“Ja, en het leuke van ontwikkelen voor Learning Heroes is dat je als programmeur écht betrokken bent bij het hele proces. Bij andere organisaties programmeer je vaak aan kleine functies of deeloplossingen en heb je geen idee waar je je in de journey je bevindt. Dat is bij Learning Heroes écht anders. Wij overzien de hele scope dus lever je je bijdrage op verschillende disciplines.”
Tot slot, als we je niet aantreffen aan je bureau, waar kunnen we je dan vinden?
“Mijn grootste hobby is uit eten gaan. Gewoon echt goed uit eten gaan. Mijn vrouw en ik gaan heel regelmatig met vrienden eten. Onze twee jonge meiden zijn er inmiddels ook gek op, dus ook met het gezin zoeken we vaak een restaurant op. Verder vind je me vaak in de keuken om lekker de koken. Tot slot is beleggen een grote passie van me geworden.”
Of stuur je bericht met dit formulier
Nieuwsgierig naar wat wij kunnen betekenen voor jouw organisatie? Maak een afspraak voor een creatieve sessie!
Tijdens deze sessie krijg je handige tips en verrassende ideeën, doe je inspiratie op met onze succesvolle klantcases en ontdek je hoe jouw organisatie slimmer kan leren en beter presteren.
Laat hier je gegevens achter. Carolien, Martijn of Jordi plannen snel de creatieve sessie met je in.
Nieuwsgierig naar hoe je organisatie slimmer kan leren en beter presteren? Plan een creatieve sessie. Ontdek inspirerende en succesvolle tips, ideeën en klantcases.
Vul je gegevens in. We maken snel een afspraak.
