Nieuwe feature in eenvoudige tool vs. uitgebreide app: het verschil

Eigenlijk is de reden erachter niet zo heel moeilijk om uit te leggen, alleen is het bij IT gewoon wat minder snel te zien. Stel je een schuurtje voor dat je wil laten plaatsen. Je huurt iemand in die handig is met metselen, die egaliseert simpel even de vloer, zet een aantal muren neer, een dak en timmert de binnenkant af. Niet duur en het ziet er goed uit. Totdat het schuurtje op een gegeven moment gaat hellen, niet zo stevig staat, eigenlijk misschien wel gevaarlijk is. Maar wat maakt het uit, het is een klein schuurtje en aangezien er niet zoveel vanaf hangt valt het wel mee.

Nu pakken we ditzelfde voorbeeld maar dan hebben we het over een schoolgebouw van twee verdiepingen. Zou je dat op dezelfde manier kunnen aanpakken? In principe wel, alleen hangt er nogal wat vanaf. De risico’s zijn veel groter, er zijn ontzettend veel voorschriften en iedereen snapt dat je een dergelijk gebouw op een veel gestructureerdere en veiligere manier moet neerzetten.

Bij softwareontwikkeling is het eigenlijk net zo, het gaat vooral om de functie van hetgeen je gaat maken. Wordt het veel gebruikt, hangt er veel vanaf, is het groter? Dan is kwaliteit een hele belangrijke component. Hangt er weinig vanaf, wil je vooral testen dan valt dat mee.

Schuurtje versus schoolgebouw

In dit artikel willen we meer inzicht geven in hoe de aanpak is bij die twee typen producten. Over het algemeen kun je stellen dat de fases van zo’n ontwikkelproces verschillend zijn wanneer je zelf een eenvoudige tool bouwt en intern gebruikt, of wanneer je een complexe applicatie neerzet met honderden gebruikers.

We spreken dan ook van een “eenvoudige tool = schuurtje” en een “uitgebreidere applicatie = het schoolgebouw”.

Hoe het gaat bij een eenvoudige tool

Wat je vaak ziet bij startups of relatief eenvoudige tools, is dat er door iemand in zijn eentje gebouwd wordt aan de applicatie. Iemand een goed idee, een developer gaat ermee aan de slag en bouwt het relatief snel.
Naarmate de tool vervolgens gebruikt wordt, doen er zich bugs voor die dan reactief gefixt worden. Er is weinig risico. De applicatie heeft maar een paar gebruikers, of wordt zelfs alleen intern gebruikt.

In dit soort situaties is het ontwikkelproces misschien wel 75% van de tijdsbesteding. De andere 20% besteedt men aan het fixen van bugs, het snel deployen en er eventueel nog iets over communiceren.

Daar is helemaal niks mis mee. Zeker als in je de pilot fase van je onderneming zit, wil je snel features kunnen lanceren, experimenteren en daarvan leren. Dat geldt ook voor een interne tool die je gebouwd hebt, bijvoorbeeld voor urenregistratie. Er zijn geen externe klanten, dus experimenteren is relatief risicoloos. Je voert geen kwaliteitsborging uit zoals code reviews en unit testing. Komen er bugs uit, dan ga je die gewoon fixen zonder dat het veel problemen oplevert.

Wanneer je een uitgebreidere applicatie bouwt

Als je echter verder bent als onderneming en een meer volwassen product gebouwd hebt, zul je zaken anders moeten willen aanpakken. Denk aan grootschalig gebruikte applicatie die verbonden is met externe diensten. Stel je wilt het scannen van een QR-code toevoegen om een bepaalde actie te kunnen starten. Relatief eenvoudige feature, maar die wel meerdere afhankelijkheden kent. Je zult de applicatie goed moeten doortesten om ervoor te zorgen dat je gebruikers geen nadelige gevolgen ervaren, of misschien hun werk niet meer kunnen uitvoeren.

De mate waarin je dit doet hangt natuurlijk ook af van de complexiteit van een feature of module. Bij complexe ideeën is gedegen onderzoek nodig: wat is het doel van de feature, hoe moet het eruit gaan zien, welke afhankelijkheden kent het? Als het een bepaalde knop met een actie betreft, mag iedereen er dan op kunnen klikken, of alleen iemand met specifieke rechten? Komen er daardoor ook aspecten zoals beveiliging en autorisatie bij kijken? Waar baseren we op dat gebruikers deze nieuwe feature gaan waarderen?

Ontwikkelen

Is eenmaal alles duidelijk en gespecificeerd, dan gaan de developers aan de slag met het daadwerkelijk bouwen van de feature.

Als je dat vergelijkt met een eenvoudige tool waar ontwikkelen misschien wel 75% van de totale tijd vergt, is ontwikkeling voor een complexe tool een relatief kleiner deel van het totale proces. Misschien zelfs maar 40%. Wat moet er nog meer gebeuren?

Zeker als het gaat om complexe functionaliteiten met veel afhankelijkheden, dan gaat hier veel tijd in zitten om eventuele bugs te vinden en op te lossen. Zo heeft een grotere onderneming inmiddels allerlei kwaliteitsstandaarden waar je je aan moet houden. Processen zijn ingericht volgens ISO-normering, maar denk ook aan vulnerability scans die het correct functioneren van de applicatie automatisch controleren. Je gaat niet meer alleen testen met dummy data, maar wil je met realistische data goed en uitgebreid kunnen uitproberen.

Deployment

Werkt alles naar behoren op de testomgeving, dan zal de feature naar productie worden gezet, oftewel deployment. Ook geen kleine taak, aangezien iemand dit zal moeten begeleiden, maar ook monitoren. Gaat alles goed met het live zetten van de feature? Bij een kleine tool druk je bij wijze van spreken gewoon op de knop en is het live. Bij een complexe tool met veel gebruikers zijn er allerlei risico’s die je moet borgen. Je wilt voorkomen dat een livegang bij hen de applicatie platlegt waardoor zij hun werk niet kunnen doen.

Andere elementen rondom duurzaam ontwikkelen zijn:

• Onderhoud: is eenmaal alles live, dan kunnen er later onderhoudskosten ontstaan. Als de functie in een kritieke, complexe locatie van de software ligt, kan de tijd die wordt besteed aan het oplossen van bugs hoger zijn. Als er afhankelijkheden zijn van API’s (en dus derden), zul je deze up-to-date moeten houden.
• Documentatie: denk naast documentatie over hoe er ontwikkeld is, ook aan e-mailcommunicatie met gebruikers, handleidingen, onboarding teksten, release notes en andere vormen van communicatie of uitleg.
• Trainingskosten: bepaalde features in de software vereisen soms ook het trainen en opleiden van andere teams.
• Onvoorziene kosten: verassingen zul je altijd tegenkomen. Als een nieuwe feature veel geheugen en opslag vereist, betekent het ook dat je in de infrastructuur van je applicatie een en ander moet voorbereiden om dat te ondersteunen.