Efteleurstelling

Casper kwam met teleurstellend nieuws: het Efteling-uitje van deze week gaat niet door. De reden is er een waar we in Nederland allemaal maar al te bekend mee zijn: het gaat de hele week ongelooflijk hard regenen.

Je snapt natuurlijk wel waarom dit teleurstellend nieuws is. Ik was op X namelijk al meer dan een week bezig met het plaatsen van (thematisch) Efteling-gerelateerde berichten en had voor de dag zelf al allerlei berichten klaargezet om die dag op X te plaatsen.

Uiteraard had ik dat vooraf ingeregeld, want op de dag zelf is daar geen tijd voor. Behalve misschien de momenten waarop je in een lange rij staat voor een attractie, maar dan is het waarschijnlijk beter als ik niet plaats wat ik op dat moment denk.

Maar nu gooit Casper roet in het eten. De berichten die ik allemaal had klaargezet, moet ik nu één voor één gaan verplaatsen. En nu moet ik ook nog eens nieuwe berichten gaan verzinnen voor de dagen waarop eigenlijk mijn Efteling-berichten stonden ingepland 😡

Lui of kans?

Ik moet nu dus een lading berichten gaan verplaatsen. En ik merk dat ik weerstand voel bij die taak. Meestal als ik dat ervaar, komen er twee gedachten bij me op:

1. Luie Jeroen!
2. Valt hier iets te automatiseren of te verbeteren?

In dit geval waren beide gedachten correct. De eerste is niet zo verrassend (dat is praktisch een pleonasme), maar de tweede biedt natuurlijk wel een kans.

Xintegratie

We hebben onze CMS-X-integratie uiteraard zelf gebouwd. In ons CMS kunnen we berichten klaarzetten die automatisch op X worden geplaatst op de door ons ingevulde datums en tijdstippen. Op zich niks bijzonders: een simpele UI in ons CMS, samen met het aanroepen van de X API. Maar wel erg handig.

Waarom zelfbouw? Er zijn immers meer dan genoeg bestaande tools die dit soort dingen ook kunnen, en veel uitgebreider zijn. En waarschijnlijk ook al precies kunnen waar ik nu tegenaan loop (een manier om eenvoudig wat geplande berichten 'op te schuiven').

Het is een eeuwig terugkerende afweging: ga je iets kopen of ga je iets bouwen?

Wanneer je iets koopt, kan het behoorlijk wat tijd schelen, je krijgt volwassen software, met veel features, maar misschien niet alles wat je nodig hebt, en het werkt niet altijd even ideaal. Als je het zelf bouwt, kan je ervoor zorgen dat het naadloos aansluit op je bestaande systemen en processen, en wel alles heeft wat je nodig hebt, maar je bent er wel langer mee bezig. Welke optie (zelf bouwen of kopen) duurder is, weet je dus vaak pas achteraf.

Beide gaan uit van platonisch ideale situaties natuurlijk. Er is zat zelfbouw die niet naadloos aansluit, net als dat er zat kant-en-klare software is die helemaal niet zo volwassen blijkt.

Zelf bouwen, of kopen? Het is dus altijd een moeilijke inschatting. Maar wij denken dat we hier inmiddels wel redelijk verstand van hebben - en hebben ook een aardig track record van succesvolle softwaretrajecten. Wij kunnen deze inschatting dus wel vrij goed maken.

Ook ondervinden we inmiddels al jaren de vele voordelen van Streamline, ons zelfgebouwde in-house 'administratiepakket', dat verantwoordelijk is voor het bijhouden en beheren van onze uren, facturatie, time-tracking, geautomatiseerde rapportages naar onze klanten, en nog veel meer.

Streamline was zelfs zo succesvol dat Casper de tijd die hij nodig had voor administratie zag afnemen van twintig uur naar vier uur. Je zou denken dat met al die extra tijd hij de Efteling wat beter had kunnen regelen 😡. Zelfs Streamline kan blijkbaar niet alles oplossen!

Wacht eens even, hmm...🤔 even langs Henk lopen.

Uitbreiden

Ik kreeg Henk niet overtuigd van het belang van een Efteling Streamline-module. Terug naar het CMS dan maar weer, met onze X-integratie.

Wat had ik nodig voor mijn situatie? Als ik naar de weersverwachting kijk, ziet volgende week er goed uit. Grote kans dus dat we dan naar de Efteling gaan. Dus ik wil een manier hebben om makkelijk de datums van de geplande berichten met één of meer dagen op te schuiven, terwijl de tijdstippen bewaard blijven.

Ik kwam al snel op een simpele oplossing: in het grote overzicht moest er per rij, naast het datumveld, een knop komen om de datum één dag vooruit te schuiven.

Dit was niet de enige oplossing die ik bedacht. Ik had bijvoorbeeld ook een idee om de interface om te bouwen naar een combinatie van selecties waarmee bulkoperaties uitgevoerd kunnen worden, waarvan dit de eerste zou zijn. Een mooie future-proof, generieke oplossing: want er komen vast nog meer van dat soort operaties(™).

Het is moeilijk om de toekomst te voorspellen. Meestal zitten we ernaast. Daarom is het verstandig om met een zo klein mogelijke wijziging te beginnen en van daaruit te leren wat er echt nodig is. Vaak kom je daar pas achter tijdens het gebruik. Er zit doorgaans maar weinig overlap tussen de features die je vooraf bedenkt, en de features die je achteraf nodig blijkt te hebben.

Deze aanpak hadden we ook al toegepast op de oorspronkelijke X-integratie. Ook dit was een minimale implementatie, en pas na (exact) een maand van dagelijks gebruik, ontdekten we een volgende noodzakelijke feature. Productmensen noemen dit tegenwoordig de ‘lean’ of ‘MVP’-aanpak, maar wij echte nerds kennen dit fenomeen al veel langer, in de vorm van JIT (Just-In-Time).

Ik besloot daarom bij mijn oorspronkelijke idee te blijven: een simpele knop om het bericht één dag op te schuiven.

Goede werking, toch complexiteiten

De knop werkte uiteindelijk vrij goed. Ik was eerst bang dat het wachten op zo’n operatie te lang zou duren. Zeker als ik bijvoorbeeld een handvol berichten een dag wil opschuiven, of één bericht meerdere dagen vooruit. Maar ik was even vergeten hoe snel onze servers en software zijn. Zelfs in mijn dev-omgeving was deze operatie minder dan 100 milliseconden, laat staan op de productieomgeving. Dus dit werkte eigenlijk beter dan voorzien.

Zoals verwacht bedacht ik me tijdens het gebruiken ervan meteen een andere handige functie: soms wil ik ook een dag terug kunnen. Dus er kwam al snel een nieuwe knop bij: -1 dag.

En natuurlijk blijken er, zoals altijd bij software development, kleine dingetjes te zijn waar je in eerste instantie geen rekening mee houdt. Wat gebeurt er bijvoorbeeld als je min één dag doet en daardoor in het verleden uitkomt? Mag die operatie dan wel of niet? En als het wel mag, publiceer je het dan direct? En als het niet mag, hoe toon je dit aan de gebruiker? We kunnen een bericht tonen, maar nog mooier zou zijn om de knop uit te schakelen, zodat het helemaal niet mogelijk is. Dus zelfs de kleinste feature omvat toch meer keuzes dan je oorspronkelijk denkt.

Eenmaal de keuzes gemaakt en problemen opgelost, hebben we er nu weer een mooie feature bij gekregen in ons CMS. Ik verplaats de berichten in een oogwenk naar volgende week en sluit de dag tevreden af.

Mocht ons Efteling-uitje volgende week toch nog een andere dag worden, dan is dat voor mijn feature geen enkel probleem!

Casper gooit nogmaals roet in het eten

Maar het was natuurlijk te mooi om waar te zijn.

Nu snap ik wat Casper doet met die zestien uur die hij bespaart met onze krachtige software. Hij gebruikt die tijd om plannetjes te smeden om mij dwars te zitten! 🤬✊

Dit is dus zo'n mooi voorbeeld van hoe er altijd weer nieuwe situaties kunnen ontstaan. Ik had niet snel verwacht dat ik ooit een tweet (shit, ik bedoel X-bericht) een aantal maanden zou moeten opschuiven.

Maar goed: gelukkig was er niet veel tijd en werk in de vorige feature gestoken, en kan ik deze wederom proberen zo simpel mogelijk te implementeren. Na wat experimenteren, kwam ik toch uit op een datepicker, maar wel nog steeds eentje waarin de tijd bewaard blijft. Dus een bericht dat voor 10 uur 's ochtends gepland staat, staat na het opschuiven nog steeds om 10 uur.

Risico’s van deze aanpak

Er zitten natuurlijk ook risico’s aan deze lukrake, ongestructureerde aanpak. Het kan al snel leiden tot wildgroei. Iedereen die ooit met een overvolle applicatie heeft gewerkt, weet welke gevolgen zo'n aanpak kan hebben.

Maar ook hierbij is mijn ervaring dat je vooral goed moet opletten op de feedback die je krijgt en de patronen die je herkent tijdens het bouwen van software. Net zoals je niet te vroeg wilt generaliseren, wil je hier ook weer niet te lang mee wachten.

Zodra je merkt dat er een patroon ontstaat, is dat vaak het moment om even een stap terug te doen. Mijn vuistregel is meestal: als je iets voor de derde keer doet en het voelt alsof het ergens bij hoort, dan is dat waarschijnlijk het moment om er opnieuw over na te denken.

Eind goed, alweer roet

De berichten zelf zijn inhoudelijk gelukkig nog prima. Ze stonden immers alleen op de verkeerde datums.

Met deze mooie nieuwe feature ben ik nu dus volledig voorbereid op de volgende wijziging van Casper. Hij gaat me niet nog een keer te pakken krijgen.