Vorige week zal het de ruim 100.000 gebruikers van Gekko zijn opgevallen dat de onkosten module van Gekko waarin je bonnen en andere inkoopfacturen opslaat, er net iets anders uitziet. Maar ook dat het systeem veel sneller en gebruiksvriendelijker is geworden. Het is zo’n verbetering dat je je kan je afvragen waarom we dit niet veel eerder hebben gedaan. Daarom een kort overzicht over hoe wij Gekko in de afgelopen jaren hebben ontwikkeld en waarom deze verbetering in de onkosten module nu pas beschikbaar is.

Hoe je begint met de ontwikkeling van een nieuw softwareprogramma

Als je begint met de ontwikkeling van een programma als Gekko (of ieder ander softwareprogramma), dan is het onverstandig om te beginnen met het bouwen van een programma wat direct “af” is. Ter illustratie, de eerste versie van Gekko had bewust beperkingen. De eerste versie van Gekko was al wel gericht op zzp’ers maar er zaten nog btw en omzetbelasting rapportages in voor diezelfde zzp’ers. Ook was er nog geen mogelijkheid tot urenregistratie en km registratie en waren de apps en functie veel beperkter. Het was wel een heel handig programma voor een zzp inkomstenbelasting e.d., maar je was nog niet hét programma voor kleine ondernemers. En daarom hebben we na die eerste versie nog ruim zeven jaar verder moeten ontwikkelen om het programma te krijgen waar het nu is. 

We hebben Gekko dus gebouwd door steeds kleine incrementele verbeteringen aan te brengen aan het bestaande systeem. Het voordeel hiervan is dat je tijdens de ontwikkeling nog aanpassingen kan maken. Tijdens het bouwen kom je er namelijk vaak achter dat je originele plan toch niet helemaal klopte of dat mensen net iets anders willen dan jij vooraf had bedacht.

Begin altijd met het Minimal Viable Product

De eerste versie van Gekko was wat men ook wel noemt een “Minimal Viable Product” of MVP. Een MVP is de simpelste versie van je product of dienst waarmee je toch kan testen of het aanslaat. Je probeert het zo snel mogelijk te bouwen en dan voor te schotelen aan potentiële klanten. Als de klanten dat MVP al ok vinden en er bereid voor zijn om iets voor te betalen, zit je goed en heb je waarschijnlijk een goed nieuw product of dienst (voor meer tips over wat goede startup ideeën zijn, bekijk dit blog; verplichte kost voor iedere startende ondernemer). 

Voor Gekko was het MVP een heel simpel online programma waarmee je onkosten kon bijhouden en facturen kon versturen. We hadden deze versie binnen drie maanden klaar en gelanceerd. Vanwege de korte ontwikkelingstijd, hadden we de ontwikkeling ook erg simpel gehouden. Want we gingen er vanuit dat we als het product zou aanslaan, we verbeteringen en toevoegingen konden maken. 

Ons MVP bestond in wezen uit een server (centrale computer) waarin we de gegevens (de bonnen en factuurtjes) konden worden opgeslagen en vervolgens hadden we een bestaand frontend “framework” gebruikt waarmee je toegang kon krijgen tot de server. De server was in wezen dus een soort centrale computer waarop iemand een factuur kon maken. En het framework gaf je een directe interface waarmee je die computer kon gebruiken vanaf jouw eigen computer. 

Een MVP is meestal alleen een beperkt prototype wat niet kan opschalen

We hadden dus ons MVP gelanceerd binnen drie maanden! En het was zeker geen slecht product want er waren tenslotte klanten die ervoor wilden betalen. Al kregen we wel veel feedback en kritiek. Zo moesten er meer features komen zoals km registratie, urenregistratie, rapportages, mobiele applicaties, etc. (er was zelfs iemand die er op stond dat we een oplossing voor inkomsten in natura maakten al bleek dat niet algemeen gedragen). Maar de belangrijkste kritiek was dat het systeem niet erg snel was. Je moest vaak voor simpele handelingen een paar seconden wachten voordat het systeem was geladen en bovendien leek het systeem langzamer te worden.

Dat laatste kwam doordat ons MVP niet was gebouwd om snel te zijn en al helemaal niet om snel te zijn voor grote groepen gebruikers. Ons interface framework waarin gebruikers werkten, was namelijk een bestaand interface framework wat we in eerste instantie alleen oppervlakkig hadden aangepast voor Gekko. Echter, daar zaten twee problemen aan. Allereerst was het framework niet specifiek voor Gekko maar een “one-size-fits-all” framework. Dat betekende dat het een niet erg efficiënt framework was en als je bijvoorbeeld een bonnetje wilde toevoegen, dan kostte dat behoorlijk wat capaciteit van de server. Bovendien werkte alle gebruikers op één en dezelfde server. En daardoor moest die ene server heel hard werken om al die mensen Gekko te laten gebruiken. Dat is zoiets als één computer gebruiken om met meerdere mensen een computerspelletje te spelen. Bij de eerste paar spelers gaat dat prima, maar als je meer en meer spelers toevoegt, wordt je computer steeds langzamer en uiteindelijk zal deze crashen.

De structuur van het MVP aanpassen voor massaal gebruik

De eerste versie van Gekko was dus een aardig product en zeker een goed MVP. Maar het was zeker nog niet geschikt als massale oplossing. Iedere extra gebruiker kostte dusdanig veel capaciteit dat het systeem zou uitvallen als we in één keer een grote influx van gebruikers zouden hebben gehad. 

Bovendien was het erg onhandig dat alles op één vast framework zat. Als je van zo’n framework één onderdeel aanpast, heeft dat vaak ook invloed op een ander onderdeel. Daarom moesten we voor iedere nieuwe ontwikkeling heel veel testen om er zeker van te zijn dat ook andere onderdelen van het framework niet werden beïnvloed. Bovendien kost het live zetten van een aanpassing veel tijd. Iedere keer moet je het hele framework opnieuw laden op je server. En dat kost veel “downtime” want dat is een beetje alsof je iedere keer een software update op je computer of je telefoon moet uitvoeren. Die kosten tijd en tijdens zo’n update kan niemand het systeem gebruiken, net zoals bij een update op je eigen telefoon.

Sneller modulair ontwikkelen

Gelukkig hadden we voor al deze problemen een goede oplossing. We konden namelijk onderdelen van het systeem waar we aan werkten buiten het originele backend framework plaatsen in een soort mini applicaties. Mini applicaties zijn stukjes code die een bepaald onderdeel van het programma besturen. Bijvoorbeeld een mini applicatie die je instaat stelt een factuur te laten zien en op te maken. 

Het voordeel van deze mini applicaties was dat we dat stukje code buiten het bestaande framework konden halen zodat we er makkelijker aan konden werken en aanpassingen konden maken, zonder dat het hele framework zou worden beïnvloed. Maar belangrijker nog was het feit dat we deze mini applicaties niet op onze eigen servers hoefden te draaien, maar op de computer van de gebruiker. Voor het opmaken van een factuur hoefde je dus geen servercapaciteit meer te gebruiken maar kon je gebruik maken van een klein programmaatje wat op je eigen computer draaide. Het lijkt dus een beetje alsof je een app gebruikt op je telefoon. Die draait ook op jouw eigen telefoon (alleen draaien deze mini applicaties in je browser).

Dit scheelde erg veel server capaciteit omdat we niet langer je hele interface op onze eigen servers hoefden te draaien maar je een mini applicatie kunnen sturen waarmee je bepaalde taken jouw eigen computer kon laten uitvoeren. En als je een aanpassing maakte in je account (bijvoorbeelde een factuur verstuurde) dan kon de mini applicatie dit doorgeven per API of “Application Programming Interface” aan onze server. Een API is een methode om gegevens tussen computers uit te wisselen. Via een API wordt alleen ruwe data uitgewisseld en er zit verder geen menselijke interface in die het begrijpelijk maakt voor een mens. Maar daarom gaat het wel veel sneller en vergt het minder capaciteit. En voor een computer maakt het niets uit hoe de interface eruit ziet, zolang het maar de data krijgt.

Open Source ontwikkeling van Applicaties

Er zitten dus allemaal voordelen aan dit soort applicaties: het kost veel minder server capaciteit zodat het systeem meer gebruikers sneller kan bedienen. Bovendien stelt het ons in staat om aan één mini applicatie tegelijk te werken zonder dat we hele framework hoeven aan te passen. Echter er zit nog een heel belangrijk voordeel aan het werken met mini applicaties. We kunnen applicaties veel gemakkelijker en sneller ontwikkelen via Open Source Development. 

Open Source Development werkt als volgt. Gekko is een boekhoud en administratie tool voor kleine ondernemers. Gekko heeft dit systeem zelf ontwikkeld en het totale systeem is auteursrechtelijk beschermd en eigendom van Gekko. De code van het systeem schermen wij dus af en als iemand die code probeert te gebruiken om z’n eigen boekhoudsysteem op te zetten, dan zullen we dat weigeren en zullen we daar (juridische) stappen tegen nemen.

Echter omdat we nu mini applicaties hebben, kunnen we dergelijke mini applicaties gemakkelijk scheiden van het totale programma. Neem bijvoorbeeld een kalendertje op een factuur waarmee je de datum kan selecteren op je factuur. Dat is ook een voorbeeld van een mini applicatie die we gebruiken op Gekko waarmee je gemakkelijk de datum kan selecteren. Maar deze applicatie op zichzelf is niet wat Gekko bijzonder maakt en een handig boekhoudprogramma. Bovendien zou je deze mini applicatie met wat kleine aanpassingen ook prima kunnen gebruiken in een ander product. Denk bijvoorbeeld maar aan een site van een reisbureau waarop je moet aangeven op welke dag je wil boeken. 

Als een andere ontwikkelaar onze kalender applicatie zou gebruiken, zou dat die ontwikkelaar ontzettend helpen terwijl het Gekko eigenlijk niet zou schaden. Sterker nog, er zitten grote voordelen aan om dit soort applicaties te delen met andere ontwikkelaars. Want als iemand jouw eigen applicatie gebruikt, maakt die weer verbeteringen / veranderingen aan jouw applicatie die jij vervolgens ook weer kan gebruiken. Bovendien kun je in een dergelijke community van ontwikkelaars ook toegang krijgen tot applicaties die je anders helemaal zelf zou moeten ontwikkelen. Het kan dus geen kwaad om je code beschikbaar te stellen en je kan er bovendien veel sneller en beter door ontwikkelen. Veel van de mini applicaties die wij maken stellen wij daarom ter beschikking voor andere ontwikkelaars en wij gebruiken ook veel applicaties van andere ontwikkelaars. Dit soort Open Source Development is de standaard voor zowel kleine als grote software ontwikkelaars. 

De wet van de remmende voorsprong: legacy in software

Micro applicaties geven ons dus de mogelijkheid om heel snel te ontwikkelen. Dan zullen sommige mensen zich afvragen waarom bepaalde ontwikkelingen dan zo lang duren? Sterker nog, als we zo snel kunnen ontwikkelen en al 7 jaar lang verbeteringen aan het aanbrengen zijn, waarom lijkt de eerste versie van Gekko dan zo op de huidige versie van Gekko? Als je bijvoorbeeld de originele kosten module uit 2014 legt naast wat we net hebben gelanceerd, dan lijkt het wel erg op elkaar...

De reden is dat de theorie en de realiteit van ontwikkeling na verloop van tijd nogal uiteen lopen. In theorie gaan we naar een situatie toe waarbij we allemaal mini applicaties keurig naast elkaar hebben draaien die allemaal verbonden zijn met een API naar onze backend server. In realiteit is het echter binnen de kortste keren een grote wirwar van APIs, applicaties, frameworks etc. Dat komt omdat als je steeds nieuwe applicaties introduceert die applicaties ook steeds geavanceerder worden. En vanwege de snelheid van ontwikkeling krijg je daardoor dus oude applicaties naast veel nieuwere applicaties. En die verschillende applicaties kunnen conflicteren. Sommige gebruiken bijvoorbeeld een bepaald type API of vereisen bepaalde aanpassingen aan de backend server. Terwijl andere applicaties daar weer niet op kunnen draaien. Om het allemaal draaiende te houden wordt je systeem steeds complexer. En dat heeft natuurlijk allemaal negatieve consequenties voor de snelheid van ontwikkeling.

Gekko adopteert daarom een nieuw front end framework

Dus om een open deur in te trappen: software ontwikkeling is complex. Maar specifieker, software ontwikkeling heeft heel veel last van legacy waarbij oude applicaties gecombineerd worden met nieuwe applicaties. Dat is ook de reden dat bijvoorbeeld banken zo ontzettend vaak storingen hebben. De gemiddelde bank bestaat al decennia en zij waren bovendien de eerste die gingen “automatiseren”. Daarom hebben ze super veel oude systemen die in combinatie met nieuwe applicaties conflicteren. De drie grootbanken ING, ABN en Rabo hebben bijvoorbeeld nog systemen in gebruik die origineel in de jaren 80 zijn gemaakt. Voor een software ontwikkelaar nu hadden die systemen net zo goed in het Latijn kunnen zijn geschreven.

Om een dergelijke situatie te voorkomen, heeft Gekko daarom een nieuw front end framework geadopteerd: het Vue framework. In wezen zorgt dit Vue framework ervoor dat alle verschillende applicaties die op verschillende momenten zijn gebouwd, samen kunnen werken in één framework wat op je computer draait. Hierdoor is er minder overlap tussen functies, heeft je computer minder moeite met het draaien van de applicatie, wordt er minder gevraagd van de backend server en kunnen we sneller nieuwe applicaties ontwikkelen binnen dit framework.

Betekent dit dat we sneller nieuwe ontwikkelingen zullen introduceren?

Ja. Met dit nieuwe framework kunnen we veel sneller ontwikkelen en het is dus waarschijnlijk dat eerdere nieuwe verbeteringen en functies worden gelanceerd. Het Vue framework zorgt er nu eenmaal voor dat er meer structuur komt in het product waardoor ontwikkeling sneller zal gaan.

Tegelijkertijd moeten we ons wel realiseren dat ontwikkeling niet blijft stilstaan en dat over een paar jaar ook dit Vue framework verouderd is. En dat we dan dus weer in een situatie zitten waarin het systeem te complex wordt en we een grote aanpassing moeten maken in de structuur om ervoor te zorgen dat we kunnen doorontwikkelen. Sterker, we hebben al verschillende keren eerder een nieuw frontend framework moeten adopteren om het systeem werkbaar te houden. Vijf jaar geleden hebben we bijvoorbeeld Angular geïmplementeerd, een nu verouderd framework wat destijds een reusachtige sprong voorwaarts was ten opzichte van het framework wat we daarvoor gebruikten DjangoJS.

Bovendien moet je je wel realiseren dat de adoptie van dit nieuwe framework niet betekent dat direct het hele systeem is aangepast naar dit nieuwe framework. Om alle onderdelen van Gekko aan te passen, duurt jaren. Sterker nog, de reden dat de kosten module tot deze week zo traag was, was omdat dit nog één van de weinige onderdelen was die nog niet in het verouderde Angular werkte, maar nog in het nog veel oudere DjangoJS. Je leest het goed: de vorige keer dat we een dergelijke aanpassing maakten, was het nieuwe framework alweer verouderd nog voordat we klaar waren met vervangen van het oude framework.

Dus we zullen nog heel verder moeten ontwikkelen en voorlopig zal Gekko een complex product blijven waar heel veel slimme mensen aan moeten blijven werken. Tenslotte, software ontwikkeling is complex. Gelukkig vinden wij dat iets wat het zo leuk maakt!