Iedere software ontwikkelaar zal het herkennen, Het Eureka Moment. Dit is het moment waarop je plotseling inziet hoe je een bepaald probleem moet oplossen. We hebben ze in allerlei soorten en maten en op de meest vreemde momenten. Ik was er bij hoe iemand op zijn eigen verjaardagsfeest een inval kreeg hoe hij het probleem van de postsortering moest oplossen (voor die tijd hadden we nog geen Postcodes en daarna wel). Hij liep midden in een gesprek naar zijn bureau om het te noteren, anders zag onze postcode er nu vast anders uit…

Volgens de overlevering was het Archimedes die als eerste “Eureka” riep toen hij de naar hem genoemde natuurkundige wet bedacht terwijl hij in bad zat.

Dit soort Eureka Momenten hebben een grote impact, maar vooraf kunnen we dat niet weten. We kunnen niet zeggen: “Ik ga vandaag een grote uitvinding doen” of “Ik denk dat ik straks een geweldig inzicht krijg”. Het is iets dat ons min of meer overvalt, maar het kan ook een probleem oplossen waar we misschien al een tijd over aan het peinzen zijn.

Wat is een Eureka Moment?

De definitie van Een Eureka Moment volgens Merriam Webster: “Een moment van plotselinge, triomfantelijke ontdekking, inspiratie of inzicht”.

Wikipedia zegt er het volgende over:

Het eureka effect (ook bekend als het eureka moment) verwijst naar de algemene menselijke ervaring van het plotseling begrijpen van een voorheen onbegrijpelijk probleem of concept. Sommige onderzoeken beschrijven dit Aha! effect (ook bekend als inzicht of openbaring) als een eigenschap van het geheugen, maar er bestaan ​​tegenstrijdige resultaten over waar het precies in de hersenen plaatsvindt, en het is moeilijk te voorspellen onder welke omstandigheden men een Eureka moment krijgt.

Wat wel duidelijk is dat hoe groter en abstracter het idee is, hoe meer tijd en geld en kost om het te realiseren. Met andere woorden, het vergt meer om grote, abstracte ideeën tot een goed einde te brengen.

Sommige van mijn eigen Eureka momenten staan me nog heel goed bij. Bijvoorbeeld het idee voor de checklisten van ITpedia in mei 1989 in het trappenhuis van ons toenmalige kantoor.

Hoe ontstaat een Eureka Moment?

Niet iedereen heeft Eureka momenten of althans niet vaak. Het zijn meestal de mensen die al een tijdje bezig zijn met een bepaalt probleem en daar alle facetten al van kennen. Dan hebben we het over het moment waarop alle puzzelstukjes op zijn plaats vallen. Het triomfantelijke gevoel ontstaat door dat de weg er naartoe lang en moeizaam was. Het voelt als een overwinning.

Minder vaak komt een nieuw idee zonder aanleiding voor. Hoe kom ik bijvoorbeeld nu ineens op het idee om over het Eureka Moment te schrijven? (Het idee overviel me vanmorgen tijdens het tandenpoetsen). En welke conclusie ga ik aan het eind van dit artikel trekken? Heb ik een nieuw probleem ontdekt en gaan we op zoek naar een oplossing?

Verschillenden soorten Eureka momenten in de IT

In de IT kennen we verschillende momenten waarop we een Eureka ervaring kunnen hebben:

1. Als we een probleem voor het eerst onderkennen en doorzien.
2. Het moment waarop we inzien dat software mogelijk een oplossing kan bieden.
3. Als we door hebben hoe we die software moeten gaan ontwerpen en ontwikkelen.
4. Als we een doorbraak bedenken tijdens het programmeren.
5. Tijdens het oplossen van bugs in bestaande programmatuur.

De oplossing hoeft niet perse hoogdravend te zijn. Het kan uit de ervaring van een teamlid komen die zegt het probleem eerder te hebben opgelost bij bedrijf X met SaaS oplossing Y.

1 2 en 3 Als we een probleem onderkennen en de software oplossing bedenken

De momenten 1, 2 en 3 volgen elkaar meestal in een snel tempo op tijdens een Eureka moment. We zien een probleem, bedenken dat er software voor moet komen en zien ook op welk platform dat kan. Meestal hebben we dat binnen een uur in ons hoofd zitten, maar er kan ook een langere tijd overheen gaan. Bij elkaar noemen we het “een briljant idee”.

4 Als we een doorbraak bedenken tijdens het programmeren

Dit moment staat los van de andere soorten. Tijdens het programmeren kunnen we problemen tegenkomen die we niet hadden voorzien. Soms functioneel, soms technisch. Ze kunnen een aantal oorzaken hebben:

• In sommige modules komen alle data en functies samen om het kernprobleem op te lossen. Het is de meest complexe module van het systeem en zal het meeste worden gebruikt. De ontwikkeling er van vraagt meestal meer dan gemiddelde creativiteit.
• Het ontwerp is niet consequent en verhoudt zich niet goed tot de oplossingsrichting.
• De IT stack is niet geschikt of onvolledig om het probleem op te lossen.
• Integratie en koppeling met andere platformen is moeilijk te realiseren.
• Nieuwe user requirements sluiten niet aan op het oorspronkelijke idee.
• Security of performance eisen staan haaks op de functionele eisen.

De ontwikkelaar heeft dan een hoofdpijndossier te pakken waarbij een Eureka moment zeer welkom is.

5 Tijdens het oplossen van bugs in bestaande programmatuur

Bugs in programmatuur kunnen ware hoofdbrekers zijn. Hoe zit het en waarom kan ik er niets over vinden in het ontwerp? Wat maak ik ergens anders kapot als ik voor deze oplossing kies? Complexe bugs zijn net puzzels met soms verstrekkende gevolgen. Als dan een Eureka moment uitblijft is een work around nog de enige optie.

Een Eureka Moment moet een briljant effect opleveren

Dat is een van de kenmerken van een Eureka Moment, de oplossing is ideaal en briljant. In eerste instantie word je getroffen door een lichtflits, het licht schijnt over al. Maar al snel gaat je hoofd werken en denk je na over de implicaties. En binnen een uur besef je of het daadwerkelijk technisch haalbaar is. Het idee ebt ook snel weg als je te veel gegronde bezwaren bedenkt, maar soms blijft het hangen en komt het veel later pas tot wasdom.

Is een Eureka moment altijd mogelijk?

Nee dus. Soms moeten we gewoon toegeven dat er geen andere oplossing bestaat dan een Work around of het beëindigen van een project. Meestal is dat echter het gevolg van de voorwaarden van het project (tijd en geld). Als een oplossing door een planning wordt afgedwongen levert dat vaak een halfbakken resultaat op of een work around. De stekker wordt er gewoon uitgetrokken en krijgen we niet de kans om het Eureka moment af te wachten. We zeggen dan dat we later wel een echte oplossing gaan bedenken maar dan komt het er vaak niet meer van (Lees ook Technische schuld van een Scrum-team). Gevoelsmatig denk ik dat er dus wel altijd een Eureka Moment van betekenis mogelijk is mits tijd en geld geen probleem zijn.

Is het Eureka effect altijd nodig?

Er zijn best veel saaie projecten die draaien op routine en zonder problemen tot een goed einde komen. Dat zijn projecten waarbij het Eureka effect niet noodzakelijk is. Als het wel komt kan het echter leiden tot een waardevolle toevoeging.

Een Eureka moment laat zich niet plannen

We komen nu dichter bij de kern van mijn betoog. Het zal duidelijk zijn dat Eureka momenten noodzakelijk zijn voor het realiseren van briljante software, maar helaas, ze zijn niet te plannen. Dat is een probleem voor:

• De business die Agile teams nodig heeft voor het oplossen van meerdere problemen.
• Finance die de kosten van die teams en de baten van de oplossing moeten begroten.

Feitelijk zijn dit de problemen waarmee ieder IT project, ongeacht de methodologie, te kampen heeft. De planning en de begroting kloppen nooit.

Eureka momenten stimuleren en cultiveren

Dit brengt mij op het idee dat we Eureka momenten zoveel mogelijk moeten stimuleren en vrij baan moeten geven om vervolgens in onze bedrijfscultuur op te nemen. Om dat te kunnen bereiken moet worden voldaan aan de volgende voorwaarden:

• We moeten vrij en ongelimiteerd kunnen brainstormen.
• Er is een inspirerende omgeving nodig waar veel ruimte is voor creativiteit.
• We werken in multidisciplinaire teams.
• Het volgen van inspirerende trainingen en lezingen is vast onderdeel van onze organisatie.
• Het onderhouden van collegiale contacten buiten de organisatie wordt gestimuleerd.
• Er is geen druk van tijd en geld, als je er bovenop gaat zitten kan een idee niet groeien.

Eureka momenten in teamverband

Het Eureka Moment en het Agile – SCRUM werkproces

Eureka momenten komen moeilijk tot stand binnen de standaard ontwikkelmethodes Waterfall en Agile – Scrum. Dat komt omdat deze ontwikkelmethodes vooral gericht zijn op het werken in een bepaalde structuur, terwijl Eureka effecten zich op willekeurige momenten voordoen.

• Waterfall: De fases Requirements analyse, Ontwerp, Ontwikkelen en Testen volgen elkaar op nadat de voorgaande fase is afgesloten. Een Eureka moment kan dus alleen betrekking hebben op de fase die onderhanden is. Terugkomen op een eerdere fase is een kostbare ingreep.
• Agile – Scrum: Een onderhanden Sprint heeft betrekking op uitgewerkte User Stories. Een User Story komt pas in een sprint als hij voldoende gedetailleerd is. Een User Story is dus eerder het gevolg van een steeds fijnere uitwerking dan van een briljante inval. Een Eureka moment kan dus de hele Backlog in de war sturen. Bovendien moeten we een User Story bevriezen zodra hij in een Sprint wordt opgenomen.

Als je een van deze methodes gebruikt adviseer ik om de Change Control Board meer invloed te geven en te verzwaren met meer ontwikkelexpertise en materiedeskundigen. Deze groep kan brainstormen en beslissen over de Eureka invallen. Ondertussen kunnen de Waterfall en Agile werkprocessen gewoon ongehinderd doorgaan.

Eureka Moment betekenis bij DevOps

In de ware toepassing van DevOps is sprake van een continue stroom van plannen, ontwerpen, testen, codering en beheer. We spreken daarbij vaak over Continuous Testing en Continuous Delivery, het liefste over Continuous Everything. Hoewel we niet voortdurend Eureka Momenten hebben is het in zo’n cyclus relatief eenvoudig om Continuous Eureka Momenten in te passen. Bovendien zijn Ontwikkeling en Beheer in deze methode met elkaar versmolten. Daardoor kan een idee heel gemakkelijk betrekking hebben op meerdere vlakken van de ICT zonder dat dit ernstige gevolgen heeft voor het proces.

Mijn conclusie

Discussieer mee op ITpedia LinkedIn of op Financial Executives LinkedIn.