Klinkt goed, maar Bezint Eer Ge Begint!
Vijf punten om rekening mee te houden.

No code, een term die steeds vaker opduikt en regelmatig wordt genoemd. En dat is niet voor niets: het is een tijds- en kostenbesparende manier van programmeren. Hierdoor wordt het voor veel meer mensen mogelijk om apps of websites te maken. Maar er zijn ook flink wat nadelen aan deze hype verbonden. Het kan zelfs zo zijn dat jouw ambities niet passen bij deze methode. Dit zijn onze vijf valkuilen van no-code waarvan wij vinden dat je je er bewust van moet zijn voordat je beslist er mee te starten.

Maar laten we beginnen met uitleggen wat No Code eigenlijk is.

No Code tools stellen je in staat om software of applicaties te ontwikkelen zonder ingewikkelde code te hoeven schrijven. In plaats daarvan maak je gebruik van visuele tools waarmee je functionele componenten selecteert en plaatst in een visuele flow. Met behulp van een bibliotheek met functies kun je bijvoorbeeld een app ontwikkelen zonder technische skills nodig te hebben. Dit maakt de ontwikkeling van applicaties toegankelijker voor veel meer mensen. Het is dan ook geen verrassing dat iedereen die technische oplossingen nastreeft, deze methode kan gebruiken om ze te realiseren. Tenminste, zo lijkt het.

Vergelijk het met het gebruik van een Content Management Systeem (CMS). Bij een CMS kun je gebruik maken van HTML of WYSIWYG (What You See Is What You Get).

 

Vergelijk het met het gebruik van een Content Management Systeem (CMS). Bij een CMS kun je gebruik maken van HTML of WYSIWYG (What You See Is What You Get). Met HTML heb je de mogelijkheid om “achter de schermen” van de website te werken: je schrijft niet alleen de webtekst, maar geeft ook code commando’s, zoals bijvoorbeeld het vetgedrukt maken van tekst. Met de WYSIWYG-optie werk je in een visuele weergave, zodat je direct kunt zien welke wijzigingen welke impact hebben op het eindresultaat.

Toch is het gebruik van No Code-methoden niet zonder nadelen. Sterker nog, No Code heeft belangrijke nadelen waar je rekening mee moet houden.

Nadeel 1: Wel de kosten, niet de voordelen van uitbesteding

Het grootste nadeel is dat No Code niet bepaald goedkoop is. Sterker nog, vaak is het net zo duur of zelfs duurder dan uitbesteding of nearshoring. Daarnaast biedt het product geen garantie en bespaart het geen tijd voor organisaties. Immers, medewerkers moeten aan de slag met de No Code-oplossing, wat eigenlijk alleen maar extra kosten met zich meebrengt. Uiteindelijk is No Code dus vaak net zo duur als iets laten programmeren door een externe partij in West-Europa. Het ontbreken van garanties maakt het ook nog eens risicovoller.

Nadeel 2: Beperkte mogelijkheden met No Code

No Code wordt vaak gebruikt door afdelingen binnen organisaties die een oplossing zoeken voor een specifiek probleem. Het is snel en gemakkelijk om software te ontwikkelen die een bepaalde functie vervult die anders handmatig zou moeten worden uitgevoerd. Er wordt echter weinig aandacht besteed aan de gebruikerservaring (UX). Er wordt alleen een functionele oplossing ontwikkeld voor het probleem.

Vergelijk het met een plakbandje: een snelle en functionele oplossing die sterk genoeg is om bepaalde problemen aan te pakken. Maar meer complexe en uitgebreide problemen worden meestal niet opgelost met een plakbandje. Hetzelfde geldt voor No Code. Een vergelijking met legoblokjes is ook van toepassing: de mogelijkheden zijn beperkt. Daardoor ligt de focus al snel op wat er gebouwd kan worden met de “blokken”, in plaats van wat de gebruiker echt nodig heeft.

Nadeel 3: No Code is niet schaalbaar

Vaak bieden No Code-oplossingen beperkte mogelijkheden om te integreren in private clouds, IT-infrastructuur van organisaties, oplossingen van derden, verouderde systemen of systemen die intern worden beheerd. Hierdoor rijst de vraag hoe schaalbaar zo’n oplossing eigenlijk is als deze niet geïntegreerd kan worden. Het antwoord daarop is dat No Code-oplossingen vaak niet schaalbaar genoeg zijn om impact te hebben op bedrijfsdoelstellingen. Voor bedrijfskritische applicaties is No Code nog niet ver genoeg ontwikkeld. Dit maakt het een zeer beperkte toepassing.

Doordat pure No Code zo geschikt is om op een efficiënte manier problemen voor afdelingen op te lossen, worden er concessies gedaan op andere gebieden. Schaalbaarheid is een serieus probleem bij No Code. Applicaties die bedoeld zijn voor meerdere afdelingen, gebruikersgroepen en markten worden zelden of nooit ontwikkeld met behulp van No Code.

Nadeel 4: Opslag van data is problematisch

Applicaties die zijn ontwikkeld met behulp van No Code integreren slecht tot niet met andere systemen. Het is dan ook een uitdaging om gegevens op te slaan die worden verzameld door dergelijke applicaties. Het is niet vreemd als gegevens niet zijn opgeslagen, niet gestructureerd zijn opgeslagen of als er verschillende kwaliteitsniveaus in de gegevens voorkomen.

Nadeel 5: Vendor lock-in

Ons laatste nadeel (en dan stoppen we) van No Code is het feit dat er sprake is van een “vendor lock-in”. Het is moeilijk om over te stappen naar een andere methode zonder ingrijpende financiële gevolgen. Ook het gebrek aan controle is zorgwekkend. De componenten die worden gebruikt, zijn immers niet door de organisatie zelf geschreven. Daardoor is het onzeker of een applicatie wel veilig is. Dit brengt serieuze veiligheidsrisico’s met zich mee.

Oftewel:

No Code is het plakbandje van het programmeren: efficiënt en effectief voor eenvoudige problemen. Het lijkt een goede oplossing voor organisaties die intern de mogelijkheden van een applicatie willen presenteren, bijvoorbeeld om innovatiekansen aan belanghebbenden binnen of buiten de organisatie te tonen.

Een alternatief voor No Code is Low Code, waarmee complexere zaken net even iets makkelijker kunnen worden geprogrammeerd. Het heeft waarde voor organisaties, zij het met beperkingen. Maar ontwikkelingen volgen elkaar snel op en wellicht is het in de toekomst mogelijk om duurzame oplossingen te ontwikkelen met behulp van No Code of Low Code.

Als je op dit moment een applicatie wilt ontwikkelen en in gebruik wilt nemen, raden we aan om echte code te (laten) schrijven. Je loopt namelijk al snel tegen beperkingen aan bij deze methode, niet alleen als je wilt opschalen, maar ook als je inzichten uit data wilt halen. Bovendien brengt het ernstige veiligheidsrisico’s met zich mee en is het de vraag hoeveel controle je hebt.