De wereld van it-technologie bevindt zich duidelijk in een stroomversnelling. Elke maand verschijnt er weer een nieuwe technologie, taal of standaard. De ene is nog niet klaar, de kinderziektes zijn er nog amper uit, of daar verschijnt al weer de opvolger.
Deze column zou makkelijk geheel gevuld kunnen worden met het opsommen van de namen van al die nieuwe technologieën van de afgelopen twintig jaar. Maar wie is er eigenlijk mee opgeschoten? Ontwikkelen ze nu applicaties sneller en beter? Het teleurstellende antwoord op beide vragen is: ‘Nee!’ Industrie en gebruikers draaien eerder rond in cirkels, en wie komt er verder mee?
De historie van de technologie voor software-ontwikkeling is bekend. In de jaren zestig en zeventig waren de lagere programmeertalen (talen van de derde generatie, de 3gl’s), zoals Cobol, RPG en Fortran dominant aanwezig. Daarop volgde de succesperiode van de 4gl’s, zoals Progress, Uniface en Usoft. In vele projecten was toen al de ervaring opgedaan dat als je ontwikkelt met een 4gl, de productie van de ontwikkelaars en de onderhoudbaarheid van de code hoger ligt dan met een 3gl.
In het kielzog van de 4gl’s ontstonden de Case- en I-Case-tools. Het grote probleem van de 4gl’s en Case-tools was hun afhankelijkheid van de leveranciers. Code en specificaties werden opgevoerd in niet-gestandaardiseerde talen. Er is zelfs een korte periode geweest waarin men sprak over 5gl’s, maar dat is nooit een groot succes geworden.
Aan het begin van de negenter jaren kwam iemand met het lumineuze idee om het mainframe vaarwel te zeggen en alles op basis van client/server-architecturen te ontwikkelen. Hiermee kregen de markt een stortvloed van producten en talen. U kunt ze zich waarschijnlijk nog wel herinneren: Object View, Power Builder, SQL-Windows, Visual Basic, de interface voor databases – Odbc, de gedistribueerde relationele database architectuur – Drda, en nog vele andere. En vijf jaar later volgde de internet-hype met een stortvloed aan nieuwe technologieën en talen. Denk maar aan Active Server Pages, Java servlets, applets en Enterprise Java Beans.
Met andere woorden, de afgelopen dertig jaar hebben veel nieuwe technologieën laten zien en gebruikers hebben veel veranderingen moeten verwerken. Maar ook al is die nieuwe technologie op diverse fronten beter dan een voorgaande, de programmeurs staan nog steeds voor dezelfde uitdagingen, zoals: hoe zorg ik ervoor dat de software geen fouten bevat, dat ze snel werkt en dat ze niet teveel netwerkverkeer genereert? Programmeurs van vandaag voeren nog steeds dezelfde strijd als hun voorgangers lang geleden, alleen hun tools zijn anders.
Waarom is er eigenlijk zo weinig veranderd? De reden hiervoor is onder andere het volgende. We maken nog steeds geen onderscheid tussen enerzijds programmeurs werkend bij een klant, zoals een verzekeringsbedrijf of detailhandel, en anderzijds programmeurs werkend bij een softwarefabrikant, zoals IBM, Microsoft of Oracle. We vinden het heel normaal dat een programmeur bij een softwarefabrikant dezelfde ontwikkeltaal gebruikt als zijn metgezel werkend bij een softwaregebruiker.
Dit is een zeer merkwaardig fenomeen, want een programmeur bij een softwarefabrikant maakt softwaretools en iemand werkzaam bij een softwaregebruiker gebruikt diezelfde tools om bijvoorbeeld financiële of andere administratieve applicaties te maken. De eerstgenoemde schrijft buffermanagers, netwerkprotocollen en ‘parsers’. Hij dient het merendeel van zijn tijd te besteden aan het ontwikkelen van zeer efficiënte en robuuste tools. Het is ook gebruikelijk dat hij een groot deel van zijn tijd spendeert aan het optimaliseren van code. Daarentegen ontwikkelt de programmeur van de softwaregebruikers voorraad- en factureringssystemen. Hij hoort zich dus bezig te houden met applicatie- ofwel bedrijfslogica.
Maar om eerlijk te zijn, dit zijn geen vergelijkbare soorten applicaties, dus je zou verwachten dat ze andere soorten tools gebruiken. Maar nee, wat is het geval; bij softwarefabrikanten en softwaregebruikers zijn dezelfde tools algemeen gangbaar. Dus is het niet verwonderlijk dat een programmeur van een gebruiker ook zoveel tijd aan technische aspecten moet besteden (dat hoort bij dat tool). Maar hij zou zich juist met iets anders moeten bezighouden, namelijk applicatielogica. Zolang een programmeur, werkend bij een softwaregebruiker, minder dan 20 procent van zijn tijd bezig is met het programmeren van applicatielogica, is er iets fout.
Vergelijk het maar eens met andere vakgebieden. Ook in andere vakgebieden gebruiken specialisten, zoals chirurgen en biologen, speciale instrumenten. Maar nergens geldt dat de instrumentenmaker voor het vervaardigen van een bepaald soort instrument ook datzelfde soort instrument weer bij het fabricageproces gebruikt – behalve in de it-branche!
Een programmeur wiens taak het is administratieve software te bouwen (en dat kan een modern systeem voor relatiebeheer of een hippe website zijn), dient tools te hebben die daar speciaal voor ontwikkeld zijn. Dus niet Java, C# of C++, want die zijn ideaal voor de softwarefabrikanten zelf. Zij horen ook niet bezig te zijn met EJB en COM+. Die technologieën hebben niets te maken met applicatielogica. Dit is software voor de softwarefabrikanten. Misschien dat de tools die de softwaregebruikers hanteren Java, C#, C++, EJB en COM+ genereren, maar dat is wat anders.
Wil de software-industrie verder komen, dan is het onvermijdelijk dat men leert een scheiding aan te brengen tussen deze twee groepen ontwikkelaars. Zolang men beide groepen dezelfde tools en talen blijft aanreiken, zal de worsteling met technologie niet voorbij gaan, en zal de vicieuze cirkel blijven bestaan: veel nieuwe technologie dus, maar geen stap vooruit!
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken. Hij is gespecialiseerd in softwareontwikkeling, datawarehousing en internet.
