Tag incrementele ontwikkeling
Schone interfaces, simpele implementaties
Het dilemma was als volgt: ofwel de deadline missen met een “goede” oplossing (dat wil zeggen: een oplossing die de REST-standaard volgt), ofwel de deadline halen met een slechte (die een uitzondering introduceert in de opzet van onze API). Maar: dat is een vals dilemma.
Twee stijlen van refactoren
Het was een tijd terug 40 graden en dat leek me, om redenen die ik achteraf niet kan bevatten, geen reden om het geairconditioneerde pand van mijn werkgever te bezoeken. In plaats daarvan bleef ik met de gordijnen dicht op mijn snikhete kantoortje zitten en begon aan een grootscheepse refactorslag. Of liever: twee refactorslagen - de ene met een gestaag toenemende hoeveelheid koortsig zweet op mijn voorhoofd, en de ander met een stabiele hoeveelheid normalehittezweet. De ene refactorslag was een ramp, de ander een succes. In beide gevallen moest ik het kantoor nadien goed luchten - dat wel.
Bewuste technische schuld
Is technische schuld erg? Niet per se, zolang de keuze voor technische schuld maar een bewuste is. Als het team duidelijk maakt dat de oplossingsrichting technische schuld met zich meebrengt en afdwingt dat er op middellange termijn tijd wordt vrijgemaakt om die op te ruimen, hoeft die schuld geen probleem op te leveren. Integendeel: dankzij die schuld zijn we in staat om op korte termijn - vóór de deadline - waarde te leveren.
Horizontale of verticale PBI's?
Een risico van horizontaal ontwikkelen is dat je veel tijd besteedt aan de back-end, om er vervolgens bij de implementatie van de front-end achter te komen dat je iets over het hoofd hebt gezien. Met als gevolg dat je alsnog verticaal aan het ontwikkelen slaat. Dat is niet alleen irritant, het is ook ontzettend inefficiënt!
Check op permissies, niet op rollen
Op een gegeven moment begon onze autorisatiecode uit de hand te lopen. De code in onze front-end was haast onleesbaar geworden van alle rollenchecks die de logica vervuilde. Erop terugkijkend, hadden we twee fouten gemaakt in onze oorspronkelijke implementatie. Ten eerste hadden we gebruikers de mogelijkheid gegeven meerdere rollen te hebben, en ten tweede bevonden onze checks zich op een te grof niveau.
De kwestie autorisatie
Onze Product Owner ging anderhalve week ondergronds met onze informatie-analist om een autorisatiematrix uit te tekenen. Toen hij het eindresultaat eindelijk presenteerde aan het team, leidde hij zijn verhaal in met de woorden: “We gaan jullie meenemen.” Dat was een slecht teken.
Incrementele versus iteratieve ontwikkeling
Als ik geen zin heb om over software ontwikkeling te lezen tijdens mijn ontbijt, zet ik een filmpje op YouTube op. Laatst keek ik er een van software architect George Fairbanks over de bijdrage van softwareontwikkelprocessen aan (het wegwerken van) technische schuld. Ik at die ochtend, als ik me het goed herinner, afbakbroodjes met jam. Het was dus in meerdere opzichten een prima begin van de dag.