Softwareontwikkeling

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

Leestijd 4 min

Door Maurits Dijkgraaf

In de afgelopen jaren heb ik veel applicaties mogen ontwikkelen. Daarbij heb ik soms applicaties gezien die ontzettend groot zijn en gebouwd door slechts één developer. Ook heb ik applicaties gezien die ontwikkeld zijn door een heel team, maar veel kleiner zijn. Hoe kan dat nou? Is die ene developer dan zo briljant en die anderen zo traag, of zit er iets anders achter?

Developer achter een laptop - PAQT.com

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.

Met 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.

Met 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.

In dit artikel spreken we dan ook van een “eenvoudige tool = schuurtje” en een “uitgebreidere applicatie = het schoolgebouw”.

Samenwerken achter een scherm - PAQT.com

De fases in softwareontwikkeling

We doorlopen de volgende fases, die per type applicatie anders ingevuld worden:

  • Bedenken: je hebt een idee en dat idee moet uitgewerkt worden.
  • Ontwikkelen: het idee wordt daadwerkelijk ontwikkeld tot een feature.
  • Kwaliteitsborging: de code wordt getest door collega’s, er wordt extra code geschreven om de schaalbaarheid te borgen, de grammatica van de code wordt gelijkgesteld aan de rest van de applicatie.
  • Functioneel testen: je gaat testen of de ontwikkelde feature ook werkt zoals dat initieel bedacht is.
  • Deployen: de feature gaat live en is beschikbaar in de applicatie voor de gebruikers.
  • Onderhouden: bugs oplossen, afhankelijkheden met derden bijwerken (denk aan API’s) etc.
  • Documenteren en communiceren: je documenteert wat er is ontwikkelt, communiceert met collega’s en

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.

Feature ontwikkeling eenvoudige tool

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.

Whiteboard uittekenen van een idee - PAQT.com

Bedenken

Nog steeds begint de ontwikkeling met het bedenken van een feature. In plaats van de korte termijn (een nieuwe feature bedenken en lanceren), denk je nu na over de toekomst: refinement. Vergt de nieuwe feature bijvoorbeeld maatwerk, of kun je bestaande bouwblokken gebruiken? Het liefst houd je de hoeveelheid maatwerk zo laag mogelijk. Dat vereenvoudigt onderhoud later en zorgt ervoor dat je makkelijker nieuwe modules kunt blijven aansluiten.

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?

Product owner met Lead developer achter een scherm - PAQT.com

Kwaliteitsborging en functioneel testen

Nadat een eerste versie is gebouwd, moet dit uitgebreid getest worden. Er is een testomgeving nodig. Maar er wordt ook functioneel getest waarbij collega’s meekijken. Doet de functie wat er verwacht wordt? Zo niet, dan zal er opnieuw tijd gestoken moeten worden in de ontwikkeling. Een ander voorbeeld is unit testing: een methode om softwaremodulen of stukjes broncode (units) afzonderlijk te testen. Per unit ontwikkel je testen en zul je verschillende testcases doorlopen.

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.

Mariette, Dennis, Kevin - PAQT.com

Duurzaam ontwikkelen

Als je als onderneming groeit en serieuzer naar je productontwikkeling wilt kijken met een blik op de langere termijn, zul je duurzaam moeten ontwikkelen. Wat komt daarbij kijken?

Als je alleen maar bouwt en bouwt, dan pleeg je uiteindelijk wel roofbouw op de toekomst: technical debt. Op een gegeven moment kom je op een punt waarbij je niet meer terug kan. Deze ‘technische schuld’ is in feite al het werk dat later ontstaat: “build now, fix later”. Dat komt doordat er gekozen wordt voor oplossingen die op korte termijn weliswaar makkelijk te implementeren zijn, maar die op lange termijn moeilijk te onderhouden. Denk aan schaalbare implementaties van je ontwikkelideeën. Iets schaalbaars bouwen kost extra tijd.

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.
Feature ontwikkeling uitgebreide applicatie
Maurits - PAQT.com

Meer dan alleen bouwen

Je ziet dat al deze elementen samen veel meer tijd en energie kosten dan enkel het bouwen van de feature. Uiteindelijk beslaat het bouwen slechts 40% van de tijd, de rest zit hem in voorbereiding, opvolging, training en documentatie. Iets waar je niet direct aan denkt, maar wat wel essentieel is voor succes.

Advies nodig over de ontwikkeling van jouw softwareproduct? Neem contact op en ik denk met je mee over jouw volgende stap.

Neem contact op met Maurits

Advies nodig over de ontwikkeling van jouw softwareproduct? Neem contact op en ik denk met je mee over jouw volgende stap.

Maurits Dijkgraaf

Alle artikelen

Advies nodig? We helpen je graag.

Maak direct een afspraak voor een adviesgesprek