Frank van Esch
Low-code is geen tegenpool van pro-code. Het is een glijdende schaal, en de vraag is bij elk geval opnieuw: waar op die schaal hoort dit thuis. Het antwoord ligt zelden aan een van de uiteinden. De meeste oplossingen die we bouwen zitten ergens in het midden, en schuiven gedurende hun leven nog op ook.
Het lastige is dat die schaal geen duidelijke streep heeft. Je merkt pas dat je een grens voorbij bent als het onderhoud begint te knellen, of als een collega een vraag stelt die je niet meer in één adem beantwoordt. Drie ijkpunten helpen ons om die beweging eerder te zien, voordat ze pijn doet.
1. Kun je het uitleggen aan wie het overneemt?
De eerste vraag is een overdrachtstest. Als een collega die geen developer is de oplossing over een half jaar nog kan volgen, zit je goed in low-code. Het is dan navolgbaar, en navolgbaar betekent onderhoudbaar.
Het kantelt zodra er formules verschijnen die niemand anders durft aan te raken. Dat gebeurt sluipend. Een filter dat begon als één regel groeit uit tot een geneste constructie met If, AddColumns en een sortering die ergens halverwege gebeurt. De app doet nog precies wat hij moet doen, maar hij is feitelijk code geworden, met een low-code jasje eroverheen.
Op dat punt helpt het om eerlijk te zijn over wat het is. Behandel het als code: zet het in source control, schrijf op wat het doet, en geef het een eigenaar. Niet omdat low-code slordig zou zijn, maar omdat iets wat je niet meer kunt uitleggen geen low-code meer is, hoe je het ook noemt.
2. Vecht je tegen het platform?
Eén workaround is prima. Elk platform heeft hoeken waar je omheen werkt, en daar is niets mis mee. Een workaround bovenop een workaround is een ander verhaal. Dat is een signaal.
Het patroon is herkenbaar. Je dwingt een gallery zich te gedragen als een datagrid, en om dat werkend te krijgen heb je een tweede truc nodig, en om die overeind te houden een derde. Op een gegeven moment ben je meer tijd kwijt aan het te slim af zijn van het gereedschap dan aan het bouwen van het ding zelf. Dan is een PCF-control of een Code App vaak eerlijker dan nog een laag eroverheen.
De toets is simpel: bouw je nog mét het platform, of er tegenin? Het eerste is low-code op zijn best. Het tweede is een aankondiging dat je richting pro-code beweegt, of je het nu leuk vindt of niet.
3. Performance en onderhoud op schaal
Een app voor tien mensen mag een seconde trager zijn. Niemand die het merkt. Bij duizend gebruikers ligt dat anders.
Schaal verandert de eisen. Queries moeten delegeerbaar blijven, zodat de database het zware werk doet en niet de telefoon van de gebruiker. Wijzigingen moeten getest kunnen worden zonder dat je het in productie ontdekt. Op dat punt wint pro-code, niet omdat het mooier is, maar omdat je er meer grip op hebt: testen, versies, en een release die je kunt terugdraaien.
Low-code en pro-code naast elkaar
Het helpt om de twee niet als beter en slechter te zien, maar als antwoorden op verschillende vragen.
Low-code is snel, zit dicht op de gebruiker en heeft een lage drempel: iemand zonder developer-achtergrond kan meebouwen en meedenken. De prijs is dat de grip afneemt zodra het complex wordt.
Pro-code geeft je controle, testbaarheid en rust bij groei. De prijs is dat je developers nodig hebt en een levenscyclus eromheen moet inrichten. Het ene is niet beter dan het andere. Ze passen bij een andere fase, een ander volume en een ander team.
De uitzondering
Soms bouwen we tóch low-code terwijl deze regels naar pro-code wijzen. Namelijk als het team de oplossing zelf moet kunnen onderhouden en er niemand is om de pro-code bij te houden.
Een oplossing die niemand kan beheren is geen oplossing, hoe net hij ook in elkaar zit. Een wat tragere app die het team zelf kan aanpassen is dan meer waard dan een strakke codebase die stilvalt zodra de bouwer weg is. Onderhoudbaarheid is ook een vorm van kwaliteit, en vaak de vorm die het langst meegaat.
De schaal blijft bewegen, ook nadat je gekozen hebt. Het vak zit niet in de eerste keuze, maar in het opmerken wanneer een geval is opgeschoven, en eerlijk genoeg zijn om er dan iets aan te doen.