In veel van mijn gesprekken met prospects stuit ik op weerstand van developers die niets moeten hebben van moderne ontwikkeltalen als Outsystems. In plaats van met behulp van visuele modelleringstechnieken (drag & drop) nieuwe functionaliteit te ontwikkelen, houden zij liever vast aan traditionele programmeertalen waarbij ze nog echt code moeten schrijven.
Terwijl ‘code kloppen’ toch echt niet meer van deze tijd is. Behalve dat het tijdrovend en dus duur is, leidt het ook lang niet altijd tot de beste kwaliteit software. Een foutje is immers snel gemaakt, onregelmatigheden in de code zijn maar moeilijk herleidbaar en veranderingen in de software blijken vaak lastig door te voeren. Maar als er gemakkelijker en betere alternatieven voorhanden zijn, waarom houden developers dan toch vast aan het traditionele programmeren door middel van code schrijven.
Onbekend maakt onbemind
Uiteraard speelt hierbij mee dat ze al hun hele carrière gewoon zijn om code te schrijven. Onbekend maakt nu eenmaal onbemind. De meeste developers die ik spreek, voeren als argument aan dat ze met de nieuwe programmeertalen de controle over de code verliezen. Feit is dat in de loop der tijd steeds slimmere programmeertalen zijn ontwikkeld die meer in de richting van niet-techneuten en daarmee van de business verschuiven. Het abstractieniveau komt hoger te liggen. En doordat ze er niet mee vertrouwd zijn, vinden developers dit vaak niet fijn. Maar dit zal slechts een kwestie van tijd zijn.
Technologische veranderingen gaan nu eenmaal snel, terwijl het menselijk denken maar langzaam verandert. Bovendien gebruikten developers het argument van de controle verliezen ook al toen werd overgegaan van het in 1-en en 0-en programmeren naar het schrijven van code. En een .Net- of Java-ontwikkelaar maakt zich vandaag de dag toch ook niet meer druk over 1-en en 0-en? Talen als Outsystems zijn in mijn ogen gewoon een logisch gevolg van deze evolutie. Het is de nieuwste generatie programmeertalen, totdat ook deze weer zullen worden vervangen door andere, nog nieuwere talen.
Maar is het erg als developers wat minder controle over de code krijgen nu ontwikkeltalen steeds meer in de richting van de business verschuiven? Volgens mij niet. Natuurlijk verandert hun werk als ze in plaats van door code te schrijven met visuele modelleringstechnieken en automatische codegeneratie nieuwe systemen kunnen ontwikkelen. Maar in mijn ogen biedt dit juist kansen voor ontwikkelaars. In plaats van een naar binnen gekeerd, tijdrovend proces, wordt het ontwikkelen van software veel sneller en dynamischer.
Ontwikkelaars zullen zich meer in de businessvraagstukken en de betreffende bedrijfsprocessen kunnen verdiepen. Ze hebben meer tijd om mee te denken met de mensen van de business, als volwaardig sparringpartner op te treden en creatiever en innovatiever bezig te zijn. En met de opkomst van it-ontwikkelplatformen is het eindelijk mogelijk om functionele wensen en eisen direct om te zetten naar werkende systemen, waardoor tijd en geld bespaard worden en de kwaliteit verbetert.
Applicaties bouwen
Door het gebruik van de in it-ontwikkelplatformen aanwezige visuele programmeertechnieken is het mogelijk om ontwerp en bouw in dezelfde stap te doen. Het bouwen/aanpassen van functionaliteit kan voor de ogen van gebruikers worden gedaan, waardoor de mogelijkheid wordt geboden om direct feedback of acceptatie te geven. En inderdaad, het wordt ook voor de klant mogelijk om zelf (deels) zijn eigen applicaties te bouwen. In de praktijk zal de 80/20-regel van toepassing zijn, waarbij 80 procent van de oplossing gebouwd kan worden met visuele programmeertechnieken. De resterende 20 procent zal nog steeds met scripting gebouwd worden.
In de aansturing van platformprojecten is het van belang om deze verhouding actief te sturen om de voordelen van het platform optimaal te benutten. In de bemensing van it-projecten zal het steeds belangrijker worden dat de platformexpert (combinatie van business analist en programmeur) goed in staat is om klantwensen te begrijpen en deze via visuele hulpmiddelen te verwezenlijken. Met de opkomst van ontwikkelplatformen zal scriptingkennis minder noodzakelijk worden, maar tegelijkertijd cruciaal blijven om kwalitatief hoogwaardige systemen te realiseren die optimaal aansluiten bij de behoefte van de business.
Adopteren
In plaats van moderne programmeertalen angstvallig buiten de deur te willen houden, kunnen developers ze dan ook maar beter zo snel mogelijk adopteren. Juist door de grote meerwaarde die het gebruik ervan oplevert, is de trend toch niet te stoppen. En zoals gezegd, door een beetje van de controle over de code uit handen te geven, krijgen ze er een hoop andere dingen voor terug, waardoor hun invloed op het eindproduct alleen maar zal toenemen. Zo bezien zijn moderne programmeertalen als Outsystems juist een zegen.
Ontwikkelaars weten dat er nog een aspect bij de 80/20 regel. Namelijk dat 80% van de tijd gaat zitten in die 20% functionaliteit die niet vanzelf meekomt met je ontwikkelplatform.
ICT wordt nog wel eens verweten naar binnen gericht te zijn. Te weinig oog voor de business te hebben, te weinig te luisteren naar de eindklant. In dit artikel zie ik eigenlijk precies hetzelfde gebeuren. De klant, hier een club met developers, wil meer controle houden. Dat zit niet in je platformproduct. Dus stel je maar dat die controle niet van belang is. Die zou je als developer juist uit handen moeten geven. Niet jij als leverancier moet veranderen naar de behoefte, maar de klantvraag moet gewijzigd worden in dat wat jij levert : Outsystems.
Wellicht zijn dan toch uiteindelijk business en ICT een stapje dichter bij elkaar gebracht 😉
Is outsystems wel een programmeertaal? Het klinkt als een visuele ontwikkelomgeving waarbij met klik en sleep ontwerp en codegeneratie samen gaan. Wat zitten lezen op het net over outsystems en lees dat er automatisch code gegenereerd wordt voor de desktop en de mobiele apparaten. Ik denk dat als je het gaat gebruiken heel goed moet nagaan of het geschikt is voor wat je ermee wilt doen. Je zit gevangen in de beperkingen van het systeem. De problemen ontstaan als je iets net even anders wilt doen. Dan zit je met een berg gegenereerde code waar je je aanpassingen wilt maken. Dan komt de verhouding 80-20 heel anders te liggen. Dat is het nadeel van een omgeving waarbij code automatische gegenereerd wordt. Het maken van aanpassingen is lastig, of het inpassen in een bestaande situatie en dan moet je nog maar hopen dat er goede code gegenereerd wordt. Hoorde onlangs ook het verhaal van een pakket van een bekende fabrikant waarbij de mensen aan de functionele kant (bussiness) de zaken bij elkaar konden klikken maar de gegenereerde sql queries van matige kwaliteit waren. Er moest ingegrepen worden in het generatie process voor het fatsoeneren van de database queries.