En de winnaar is ...

De zaal was afgeladen met tientallen computers, kilometers kabel, stapels broodjes, liters zweetdruppels en een twintigtal hard zwoegende ontwikkelaars. Kortom, de RAD race (Rapid Application Development) was in de lage landen weer van start gegaan. 

Net als vorig jaar was deze editie georganiseerd door uitgeverij Array Publications. De opzet van de RAD race is simpel. De organisatoren definiëren een kunstmatige, administratieve applicatie die de teams zonder inzage vooraf moeten uitwerken. Teams bestaande uit twee ontwikkelaars mogen dan proberen in twee dagen de applicatie te ontwikkelen. Elk team mag zelf bepalen welke software en hardware ze hiervoor willen gebruiken. Al slepen ze een oud mainframe naar binnen, dan is dat nog toegestaan. De opdracht voor de teams is duidelijk: probeer in die twee dagen een zo groot mogelijk deel van die oefening te ontwikkelen. Wie het meest heeft, is de winnaar. 

Wie werd uiteindelijk de winnaar na twee dagen van bloed, zweet en tranen? Niet een team met een product van een bekende leverancier, zoals Borland, CA, Microsoft of Oracle. De winnaar was het bedrijf RADventure met het product Clarion. De bekende producten waren wel aanwezig, zoals VisualStudio.NET, Delphi en jDeveloper, maar ze moesten het wat betreft productiviteit afleggen tegen de minder bekende 4GLs. Maar ook producten als Blue Polar, Magic en TET van EDCubed, scoorden beter.

Dit is trouwens niet de eerste keer dat een onbekende 4GL wint. In de afgelopen jaren zijn de meeste RAD races door dit soort producten gewonnen. De talen en producten die in de pers veel meer aandacht krijgen, scoren structureel niet goed. Maar waar ligt dat nu aan? De reden is niet dat de oefening speciaal geschreven is voor 4GLs, want het is een doorsnee administratieve applicatie. Hebben de verliezende teams onevenredig veel pech gehad of waren hun ontwikkelaars misschien beneden peil? Nee, de hoofdreden is gewoon dat de niet-4GLs op basis van lagere programmeertalen gebouwd zijn, 3GLs dus. En de toevoeging van alle APIs om bijvoorbeeld met database-, applicatie- of messagequeuing-servers te communiceren, heeft daar niets in veranderd. Ook hiermee zijn ze nog steeds minder goed uitgerust voor het bouwen van administratieve applicaties.

De laatste jaren van de RAD race lag het accent bij de oefening ook sterk op de business logica, ofwel applicatielogica en op integriteitregels. Terecht overigens, want die twee zaken vormen wel de essentie van een administratieve applicatie. En dan blijkt dat de lagere talen als VisualBasic, Java, C# niet veel te bieden hebben. Het blijft gewoon code krassen. De ontwikkelaars zijn het merendeel van hun tijd bezig met het oplossen van technische en performance problemen en weinig tijd voor de essentie. En bij een 4GL ligt dat precies andersom, een ontwikkelaar richt zich voornamelijk op die essentie, die applicatielogica en integriteitregels.

Maar ik hoor een aantal lezers al denken: die 4GLs waren en zijn toch leverancierafhankelijk? En dat geldt niet voor Java. En die 4GLs zijn toch interpreters en dat was toch slecht voor de performance? Deze kritiek geldt waarschijnlijk voor de meeste, oude 4GLs. Maar inmiddels zijn er nieuwe 4GLs op de markt gekomen die niet meer de code interpreteren, maar keurig Java-code genereren. Maar het nadeel blijft wel dat de opgevoerde specificaties geschreven zijn in een taal die eigendom is van de betreffende leverancier. 

Tussen haakjes, TET genereert niet alleen Java-code maar ook, als je wil, COBOL-code die vervolgens op een OS/390 mainframe kan draaien. Dus dan is je programma ook zelfs platformonafhankelijk.

Zeker in deze gewijzigde economische situatie waarin lange termijn plannen minder belangrijk zijn en het rendement van de ontwikkelaars omhoog moet, kan het geen kwaad om eens naar deze productiviteitverbeterende producten te kijken.