De verloren kunst van de eenvoud

De Tek-X (waarbij de X voor het Romeinse getal 10 staat) is een conventie voor PHP-developers gehouden in Chicago, Amerika. De conventie biedt lezingen en tutorials van meer dan vijftig bekende namen op de PHP-markt, gespreid over vier dagen.  Het hoogtepunt was de lezing van Josh Holmes, over de verloren kunst van de eenvoud.

Granny Proof

Tijdens mijn HBO opleiding werd er gewerkt met een lesblokkensysteem. Elk blok bestond uit 9 weken, waarvan 6 lesweken, 1 tentamen week en 2 projectweken. Tijdens deze projectweken kregen we de meest uiteenlopende opdrachten die in die 2 weken opgeleverd zouden moeten worden. Een daarvan was een website over het gehoor. Deze website moest informatief zijn en bovendien gebruikt kunnen worden voor presentatiedoeleinden. Daarnaast moest de GUI eenvoudig worden, want leraren moesten er op een simpele manier gebruik van kunnen maken. Uiteindelijk hadden we een GUI gemaakt die zo simpel was dat zelfs een oma er gebruik van kon maken, bij wijze van spreken, want we konden geen oma vinden die het voor ons wilde testen.  We hadden de techniek en uitvoering eenvoudig en doel treffend gehouden. Die ervaring op het HBO zou ik bijna vergeten zijn als ik niet de lezing van Josh Holmes had bijgewoond.

The lost art of simplicity

Josh opende zijn lezing met een goed voorbeeld. Hij vroeg aan het publiek, dat vooral uit developers bestond, wie er niet bij Twitter had gedacht: “Pfff dat kan ik makkelijk maken in een weekend tijd”. Natuurlijk doelde hij niet op de gehele techniek die Twitter nu behelst, maar het basisidee. Iedereen stemde in dat de basis van Twitter ontzettend eenvoudig is. De doelstelling van Twitter is korte berichten plaatsen zodat iedereen die kan volgen. En dat doet het ook en niet heel veel meer. Wat is er fout aan om enkel en alleen die vraag te beantwoorden?

Helemaal niets! Vergelijk het maar eens met een appel uit een boom plukken. De gebruiker of klant wil graag die appel hebben en niet meer  en niet minder. Er worden allerlei berekeningen op los gelaten en uiteindelijk komen developers met een soort van jetpack waarmee je naar de appel kan vliegen om deze te plukken. Op die manier wordt door alle mooie techniek het uiteindelijke doel voorbij gestreefd en de handeling te ingewikkeld, want een jetpack komt met een dikke handleiding.  Het had veel eenvoudiger geweest om een lang persoon te zoeken die eenvoudig bij de appel kan. Er is geen excuus voor een moeilijke oplossing van een eenvoudig probleem. Probeer je oplossingen dus eenvoudig te houden, zo concludeerde Josh.

Het ei en geen kip

Hij ging verder met het beschrijven van valkuilen binnen een ontwikkelproces. Aan de start van een ontwikkelproces wordt er vaak een aantal eisen gesteld, daaraan moet het uiteindelijke resultaat voldoen. Maar tijdens het ontwikkelen bedenkt een developer vaak allerlei features die, volgens hem, het resultaat ten goede zullen komen. Vaak wil de uiteindelijke gebruiker dat niet. Als voorbeeld kwam Josh met een verhaal over een ei. Wanneer je dat ei aan een developer geeft kan hij van alles bedenken met dat ei. Je zou het kunnen laten uitbroeden zodat je een kip hebt en vervolgens kunt gaan bouwen naar een legbatterij, zodat je altijd eieren hebt. Terwijl de gebruiker alleen maar een omelet wil. Met dit voorbeeld probeerde Josh duidelijk te maken dat het beter is om te maken wat de klant vandaag nodig heeft, voorkom over-engineering. Natuurlijk kun je wel  rekening houden met de toekomst, maar wederom moet je proberen daar niet in door te slaan.

The new shiney

Daarnaast vond Josh dat developers nog al eens kicken op de nieuwste technieken, the new shiney. PHP, ASP, Java enzovoort, zijn onderheven aan versies en ontwikkelingen. Developers hebben de neiging om in projecten het nieuwste van het nieuwste te willen gebruiken, terwijl de techniek zich nog niet eens bewezen heeft. Om bij het voorbeeld van het ei te blijven, ga je inderdaad dat ei bakken, maar met een gloednieuwe pan die nog maar net uitgebracht is. De pan heeft zich nog niet bewezen en misschien werkt die oude pan die je daarvoor altijd wel gebruikte net zo goed, of misschien zelfs beter. Gebruik de juiste apparaten voor de juiste klus, vond Josh.

Agile Develop Methodiek

Josh vervolgde zijn lezing met het beschrijven van hoe volgens hem softwaredevelopment zou moeten gebeuren. Meestal heeft een project een beginpunt, waar de eisen voor het project worden gesteld, en bij het eindpunt een werkend product. Er wordt vaak op een lineaire manier naar dit eindpunt toegewerkt en de klant of gebruiker krijgt in een keer het gehele project voor zijn kiezen. Dit vond Josh niet goed. Volgens hem is het veel slimmer om development, zoals hij het zelf noemde, user centered te houden. Betrek je eindgebruiker in het ontwikkelproces, uiteindelijk weet deze het beste wat de software uiteindelijk moet doen, zoals Josh het beschreef: “Study the user in his natural habitat” ofwel bestudeer je eindgebruiker in zijn natuurlijke omgeving. Josh vervolgde met het idee om meerdere deadlines te stellen. Ontwikkel in kleine hapklare brokken en presenteer die  vervolgens weer aan de eindgebruiker. Het is volgens hem beter om meerdere release te doen, liefst een keer in de twee weken, dan in een keer alles op te leveren. De door Josh beschreven methodiek is eigenlijk de Agile Development Methodiek.

Wat hebben we geleerd?

Daarmee eindigde Josh Holmes zijn lezing. Hij had iedereen aan het denken gezet en mij ook. Je gaat je gelijk afvragen, ben ik een developer die alles te mooi wil maken? Natuurlijk ben ik dat. Wil ik het nieuwste en de laatste technieken gebruiken? Ja ook dat wil ik. Gaat het ten koste van het eindresultaat of de gezette deadlines? Ja, ook dat.

Vanaf dat moment heb ik besloten om er zeker op te gaan letten en oplossing gericht te werken, waarbij ik rekening ga houden met wat de eindgebruiker wil. Uiteindelijk wil de gebruiker gewoon zijn appel of omelet, en niet een jetpack of legbatterij.