Door Tweakers Partners

Dev Summit 2024: Low-code, de scepsis voorbij?

14-11-2024 • 08:00

64

Anthony Dickinson is CTO en solution architect bij Conclusion Low Code Company. Met behulp van Mendix helpt hij organisaties te innoveren, te transformeren en bedrijfsprocessen te digitaliseren. Met zijn talk op de Dev Summit 2024, getiteld ‘Low-Code: A fool with a tool is still a fool’, hoopt hij de scepsis rond low-code weg te nemen en ontwikkelaars te overtuigen van de mogelijkheden van low-code. "En dat in het hol van de leeuw".

Al vanaf jonge leeftijd is Anthony gefascineerd door IT. "Van kleins af aan was ik geïnteresseerd in computers", vertelt hij als het gaat om zijn eerste ervaringen met een MSX, later gevolgd door een 386 en het zelf bouwen en verkopen van pc's. Na het vwo ging hij Informatica studeren aan de Avans Hogeschool in Breda. Maar aan het einde van zijn studie besefte hij dat de wereld groter is dan alleen developen. Hij volgde een master in Information Management aan de Universiteit van Tilburg, om IT in een breder perspectief te plaatsen. Bij zijn eerste opdracht kon hij goed schakelen tussen het praktische niveau - de Master Data Management-applicatie ontwikkelen, en het strategische niveau - de schaalvoordelen realiseren van globaal inkopen voor het bedrijf.

Mendix-specialist

Wat is Mendix?

Mendix is een low-code platform dat bedrijven de mogelijkheid biedt om snel en efficiënt web- en mobiele applicaties te ontwikkelen. Dankzij visuele modellering kunnen ontwikkelaars zonder diepgaande programmeerkennis applicaties bouwen via drag-and-drop functionaliteit. Mendix biedt een complete ontwikkelomgeving waarin applicaties ontworpen kunnen worden door componenten eenvoudig te slepen en te plaatsen. Dit platform ondersteunt de volledige levenscyclus van applicatieontwikkeling, van idee tot implementatie en beheer. Gebruikers kunnen datamodellen maken, interfaces ontwerpen en bedrijfslogica configureren zonder high-code.

Een groot voordeel van Mendix is de snelheid: met de low-code aanpak kunnen applicaties soms wel vier tot zes keer sneller worden gebouwd dan met traditionele methoden. De gebruiksvriendelijke interface maakt het platform toegankelijk voor zowel technische als niet-technische gebruikers.

Na meer dan twaalf jaar met Mendix werken mag Anthony zich inmiddels een ervaren specialist noemen in het ontwikkelen van low-code applicaties. Zijn eerste kennismaking met Mendix vond plaats tijdens een sollicitatiegesprek, waarbij zijn directeur hem adviseerde om kennis te maken met Mendix. "Kijk als je thuis bent eens naar de introductievideo’s van het platform", moedigde ze hem aan. Anthony volgde haar advies op en was meteen enthousiast. "Door low-code kon ik focussen op dat wat belangrijk is, namelijk het probleem van de klant oplossen", zegt hij enthousiast. Dit maakt zijn werk niet alleen efficiënter maar ook leuker, omdat hij minder tijd kwijt is aan repeterende taken. "Niet langer de 'low-level low joy-taken' maar juist meedenken met de klant, oplossingen bedenken en ze realiseren."

Om het platform beter te leren kennen, pakte hij zijn hbo-afstudeeropdracht opnieuw op en vertaalde deze naar de nieuwe technologie. Hij ontdekte dat wat hij eerder in maanden had gebouwd, nu in een week kon worden gerealiseerd. "Dat was wel echt een eyeopener. Je hebt het over applicatieontwikkeling in weken of maanden in plaats van jaren", concludeert hij. Na veel uiteenlopende projecten, zowel qua doorlooptijd als complexiteit, mag Anthony zich inmiddels een ervaren specialist noemen in het ontwikkelen van low-code applicaties.

In het hol van de leeuw

Met zijn talk 'Low-code: A fool with a tool is still a fool' op de Dev Summit 2024 begeeft Anthony zich naar eigen zeggen "in het hol van de leeuw". Hij licht toe: "Developers en architecten met een traditionele programmeerachtergrond vertellen mij regelmatig dat zij niets met low-code hebben. Ik denk dat ze het gevoel hebben dat een low-codeplatform te veel complexiteit voor ze weg abstraheert, waardoor ze zelf minder controle hebben over de details van de technische implementatie. Of dat het alleen maar voor tijdelijke of zeer eenvoudige applicaties is, die ook nog eens allemaal op elkaar lijken."

Tegelijkertijd merkt Anthony ook dat de perceptie van low-code in de loop der jaren is veranderd. Aan het begin van zijn low-codecarrière moest hij veel uitleggen en mensen overtuigen van de waarde ervan. Tegenwoordig zijn organisaties veel verder in hun acceptatie en zien ze de toegevoegde waarde. Met name aan de zakelijke kant.

"Aan de technische kant zijn er nog steeds sceptici en dat is goed. Het ene is niet altijd per definitie slechter of altijd per definitie beter dan het andere. Het gaat om het maken van de juiste afweging, voor elk project. Er zijn veel factoren die worden meegenomen in een dergelijke keuze, zoals de doorlooptijd, beschikbare capaciteit voor development en beheer, en zeker ook de licentiekosten. Het is belangrijk dat je voor iedere vraag de afweging maakt wat het juiste gereedschap is om het te realiseren. Er is nog altijd een grote vraag naar IT en software, terwijl het aanbod achterblijft. Bedrijven en ontwikkelaars zien dat low-code een bijdrage aan de oplossing levert, door het toegankelijker te maken."

Specifiek over Mendix zegt Anthony: "Mendix is van origine Nederlands en dat is op zich fijn voor ons als partner om mee te schakelen. Recent is het nieuwe Gartner Magic Quadrant over low-code gepubliceerd (een evaluatiemodel dat technologie- en dienstverleners positioneert op basis van hun 'vermogen tot uitvoering' en 'volledigheid van visie' - red.). Daar wordt Mendix voor het achtste opeenvolgende jaar als 'Leader' benoemd. Ver los van de rest eigenlijk.”

Waarom heeft Anthony eigenlijk voor de titel 'Low-code: A fool with a tool is still a fool' gekozen? "De perceptie is dat low-code lekker makkelijk is voor mensen die niet kunnen programmeren. Sommige mensen zeggen dat een huisarts niet heeft doorgestudeerd om chirurg te worden", zegt Anthony met een knipoog. “Ik beschouw low-code als een andere taal binnen de IT-wereld. Net zoals Nederlands, Engels en Chinees talen zijn, heb je dat in het programmeren ook met onder meer Java en C#. En zo heb je ook low-code. Het is allemaal het ambacht 'software ontwikkelen', net als de huisarts zorg verleent. Ik zie het als een evolutie in de manier waarop we applicaties ontwikkelen. We zijn ons steeds op een hoger niveau aan het uitdrukken. We maken al de transitie van tekstueel naar visueel coderen met low-code. Als je verder vooruitkijkt, maken we zelfs de stap naar natuurlijke taal met behulp van generatieve AI, al dan niet met de 'human in the loop'. It's easy to learn and difficult to master, dat geldt ook voor low-code."

Dev Summit app nabouwen in low-code

Anthony's inzichten en ervaring beloven een inspirerende en verhelderende sessie tijdens zijn masterclas op de Dev Summit. Hij wil ontwikkelaars prikkelen en uitdagen om open te staan voor de mogelijkheden die low-code biedt, zonder daarbij de complexiteit en diepgang van het vak uit het oog te verliezen. "Je moet als ontwikkelaar en als mens blijven leren. Ik richt me op een brede doelgroep van ontwikkelaars die nieuwsgierig zijn naar wat low-code nu precies inhoudt. Tijdens mijn presentatie verwijs ik onder andere naar het artikel 'Why Software is Eating the World' van Marc Andreessen, de oprichter van Netscape. Dit dient als basis om uit te leggen waarom er een tekort is aan ontwikkelaars en hoe low-code kan bijdragen aan een oplossing. Organisaties zijn steeds meer afhankelijk van digitale producten en hebben een groeiende behoefte aan nieuwe IT-dienstverlening."

Tijdens zijn masterclass wil Anthony verder laten zien dat low-code niet alleen geschikt is voor kleine applicaties, maar ook voor kernprocessen binnen organisaties. Zo noemt hij het voorbeeld van een applicatie waarbij low-code wordt gebruikt voor de salarisverwerking van 25.000 medewerkers, elke vier weken. "Het gaat niet alleen om kleine toepassingen of innovatie-apps, maar net zo goed om kerntaken van organisaties."

Anthony is van plan om een demo te geven waarin hij de Tweakers event-app nabouwt met behulp van low-code. Hij wil laten zien hoeveel (of hoe weinig) tijd het kost om het tastbaar en praktisch te maken voor het publiek. "Misschien denkt men dan: dit lijkt me wel iets." Anthony benadrukt ten slotte dat een low-codeplatform niet beperkt is tot basisfunctionaliteiten. Ontwikkelaars met high-code kennis kunnen gemakkelijk instromen, het platform uitbreiden en hun eigen functies schrijven. "Ik hoop dat het publiek met een open blik de zaal binnenkomt en met een nieuwe visie over low-code op zak de sessie afsluit. Als ik mensen kan laten zien wat low-code voor mij betekent, ben ik ervan overtuigd dat mensen de potentie zien en het ook willen ervaren."

Koop nu je tickets voor de Developers Summit

De kaartverkoop voor hét developers evenement begint aardig op stoom te komen, dus zorg dat je snel je kaarten in huis haalt. Tickets zijn verkrijgbaar voor 299 euro (plus 1,99 euro servicekosten) of als '3 halen, 2 betalen'-deal. Als jouw werkgever de tickets vergoedt, ontvang je uiteraard een factuur voor administratieve doeleinden. Persoonlijke gegevens worden niet gedeeld met partners.

Meer infot button

Kijk hier voor het privacybeleid van Tweakers.

Ben je student? Mail ons dan via concepts@tweakers.net, zodat je een ticket kan kopen voor een gereduceerd tarief van 75 euro.

Dev Summit partnerblok

Reacties (64)

64
64
57
9
0
6
Wijzig sortering
Het werkt eigenlijk nooit uiteindelijk en is al zo vaak geprobeerd. Het is meestal makkelijk om extreem snel en simpel een basis applicatie te verkrijgen, zoals vaak de demos in workshops, en dan loop je tegen iets geavanceerds aan dat je framework niet support of waar het niet performant genoeg is en dan ben je meer tijd kwijt om je een weg om het framework te hacken met middelmatig succes en veel complexiteit. Het enige waar ik nog wel positief over ben uit die hoek is wanneer AI je (low level) boiler plate schrijft en je dat dan met full control aanpast. Dat scheelt soms wel wat tijd, hoewel het een groot risico van bugs en verkeerd design met zich meebrengt.
Tja dat is wel vreemd dat je niet wat verder kan kijken dan dit. Ik was een van de core ontwikkelaars bij Mendix (lang geleden) en dat het concept werkt moge wel duidelijk zijn gezien het feit dat het voor 600 miljoen (als een van de meest succesvolle Nederlandse tech startups) is verkocht aan Siemens. Maar ook gewoon door de enorme waslijst aan klanten.

Testbaarheid en schaalbaarheid zijn inderdaad nadelen en het is geen one-size-fits-all oplossing, maar het ENORME voordeel dat je vergeet is dat business analisten hier zelf in combinatie met techneuten samen kunnen ontwikkelen. En dat is waar heel veel softwareprojecten uiteindelijk op falen; dat het gewoon niet doet wat het moet doen. Als je extreme performance nodig hebt dan moet je gewoon zelf bouwen, maar iets als dit voldoet gewoon voor heel veel gevallen waarbij de voordelen opwegen tegen de nadelen.
Wij gebruiken ook een groot low code platform, niet van Mendix maar ik deel je mening niet echt over dat business analisten ook gewoon kunnen mee werken. Ja zo verkopen ze het maar in de praktijk werkt het toch anders.

Ik heb mijn eigen meningen over low code, maar een is toch wel dat ik absoluut niet snap dat bedrijven hier voor kiezen vanuit het oogpunt dat het een gigantische vendor lockin is.

Alles ligt bij een partij. Sowieso moet bij ons IEDEREEN die ook meer een vinger uit steekt een dure cursus met certificaat gedaan hebben, anders mag je er niet aan komen. En dat beslist dus de partij die jij veel geld betaald voor het platform.
Daarnaast zit je dus ook 100% vast aan dat platform. Niets is portable naar iets anders. Wil je overstappen, dan flikker je dus alles in de afvalbak en mag je opnieuw beginnen.
Niet eens met een prijsverhoging? Jammer, wat ga je doen naar een andere partij?

En wat als je leverancier de fles op gaat? Niets, huilen in een hoekje.
Ook alles is online. Problemen waardoor je niet kunt inloggen (bij jou of je leverancier)? Mooi, iedereen kan uit het raam staren.

Cloud infra is soms ook een vendor lock-in, maar daar kun je rekening mee houden en je oplossingen zo bouwen dat ze of agnostisch zijn of in elk geval makkelijk kunnen worden aangepast aan een ander platform.
Low code is gewoon een hogere abstractielaag, net zoals frameworks, libraries en ook de talen zelf dat zijn. Er is niets inherent aan low code waardoor het niet zou kunnen werken.

Ik gebruik nu zelf AWS Step Functions in een “serieus” enterprise project, wat je toch zeker ook als een semi-low code oplossing zou kunnen zien. Zit ontzettend goed in elkaar en werkt als een trein.

[Reactie gewijzigd door eggsforpedro op 14 november 2024 19:19]

De liefde tussen low code and full stack development is nooit groot geweest. Het zal ook nooit groot worden. Het is vergelijkbaar voor automonteurs die liever sleutelen aan een auto uit de jaren 70 dan aan een EV.

Low code is slechts een instrument om een doel te bereiken. Als ik het moet schatten, is een low code platform geschikt voor 90% voor de administratieve toepassingen binnen organisatie.

Op de vraag of low code geschikt is om een raket mee te besturen? Dan zou ik dat toch sterk afraden? Of je daarmee een administratief proces kunt digitaliseren? Voor de volle 100 procent ja.

Wat ik hier op Tweakers merk is dat hier puristen aanwezig zijn, wat overigens niet erg is. Een vraag als, maar je kunt die oplossing toch ook gewoon maken in Java, Python, C# of Ruby schrijven? Het antwoord is ja, maar vergeet niet een het proces rondom software ontwikkeling van full stack development is heel complex. Het verlangt veel meer van jouw opdrachtgever. Hoge mate van kennis vereist van het development proces, duidelijke specificaties zijn vereist, het testen in algemene zin is omvangrijker. Dit komt vooral, omdat de faalkosten in full stack development eenmaal hoger zijn dan in low code.

Wat allicht goed is, als je geïnteresseerd bent in low code als full stack developer, pak niet Mendix om je ervaringen mee op te doen. Kies dan vooral OutSystems, uit ervaring leert dat de adoptatie bij developers gewoonweg hoger ligt. Dit komt doordat hun focus meer ligt op technische kant en dus een full stack developer. Mendix legt de focus op vooral een andere doelgroep: namelijk de business engineer.
Het verlangt veel meer van jouw opdrachtgever. Hoge mate van kennis vereist van het development proces, duidelijke specificaties zijn vereist, het testen in algemene zin is omvangrijker
Dit is deels niet waar. Waarom? Omdat opdrachtgevers zich bij low code moeten neerleggen bij de beperkingen van het systeem, en specificaties dus niet zo specifiek -kunnen- zijn. De wens “een knop die groen met paars wordt bij onhover” gaat gewoon de prullenbak in als het systeem alleen “knop is blauw” biedt.

Het feit dat programmeurs “alles kunnen” is vaak de grote valkuil bij software development. Wat dat betreft zou het goed zijn als developers vaker “nee” verkopen.

En het testen is omvangrijker omdat het daadwerkelijk kan. Dat het bij low code (vaak) zo lastig is dat niemand er aan begint, maak het zeker geen pré.

[Reactie gewijzigd door BartOtten op 14 november 2024 11:47]

Developers verkopen vaak genoeg nee, maar dan wordt dat niet geaccepteerd of wordt het toch weer wat gedraaid zodat ze toch een halve ja kunnen verkopen.

Verder zijn UXers tegenwoordig veel bezig met wat de gebruiker allemaal wil, maar niet wat goed is voor het bedrijf (hoe uitgebreid dingen werkelijk moeten zijn) en zijn elke pagina, formulier en alles te vaak uniek.

Developers hebben de afgelopen jaren ook wel vaak de neiging om dingen te overengineeren. Het splitsen van business logica met het framework, of zelfs frameworkagnostisch gaan werken. In theorie leuk, maar je gaat dat framework echt never nooit niet inwisselen. Daardoor kost het veel teveel tijd om de meest simpele dingen te doen. Ook de Do-not-repeat-yourself mantra wordt veel te ver doorgevoerd. Het is best prima als 2 formulieren op elkaar lijken en gelijksoortige code bevatten. Zelfs 3 stuks van iets is nog wel te doen. De laatste paar jaar ben ik echt afgestapt van de meest mooie wensen door te voeren in een codebase die voor de gebruiker geen fluit uitmaken.

Verder is de stap naar de cloud voor veel bedrijven of toepassing gewoon niet nodig geweest of veel te complex gemaakt. Ik zie bij mijn huidige opdracht gewoon veel gebabbel en gecommuniceer tussen enorm veel API's (waarvan je dan maar moet hopen dat het werkt zoals je denkt dat het werkt) en veel tooling zonder daadwerkelijk bezig te zijn met de kern. Data wordt 4x in verschillende databases gezet of van interface omgebouwd naar een andere. Het feit dat ons project door het aantal IP adressen was, voor een interne applicatie, blijft gewoon bizar.

Dat gezegd hebbende, ik heb ook het genoegen met Mendix gehad en eigenlijk had ik al meteen door dat dit het ook gewoon net niet was. Ze missen een eigen stijl, een eigen manier van doen waardoor je veel gestroomlijnder bezig kunt zijn en de helft van je opties kunt verbergen of weggooien. Iedereen moet maar telkens weer uitzondering op uitzondering kunnen doen en dat werkt gewoon niet voor dit soort tools. Je moet het in elkaar kunnen klikken en de business kunnen laten beslissen, maar dat is eigenlijk nooit het geval. En ondertussen is het vooral een andere manier om iets te doen, niet zozeer makkelijker, sneller of handiger, maar gewoon anders. Met ook een grote valkuil voor wat betreft prijzen of onvoorziene migraties (wat bij dit soort tools niet ongekend is)

[Reactie gewijzigd door Martinspire op 14 november 2024 12:26]

Zo is het ook bij ons qua complexiteit en issues. Om het jaar hoor je weer een PO/Manager in het bekende low code framework/mendix verhaal mee gesleurd worden en dan gaan we weer tijd en geld verspillen denkik dan.
Aan de andere kant kost vernieuwing en onderzoek gewoon geld, en is het duur tot dat het ineens een schot in de roos is en alle processen ervan kunnen profiteren.
Maar je moet ook altijd kijken of je wel een bedrijf bent voor dit soort vernieuwingen en dat je mss niet beter succes verhalen van andere succesverhalen van bedrijven kan kopieren als je past.
In algemene zin kan gezegd worden dat een uitspraak in sommige situaties waar zijn en in andere situaties niet waar ;-)

Ik zal toelichten waarom full stack development meer vereist van een opdrachtgever. Je moet je voorstellen dat veel organisaties heel goed zijn in hun draaien van hun business. Een logistiek dienstverlener weet heel goed hoe een pakketje van a naar b te brengen. Een zorginstelling weet heel goed hoe mensen beter te maken. Maar software ontwikkeling is een vak apart en grote kans dat die kennis onvoldoende is geborgd in een organisatie. Uitzonderingen daar gelaten.

Je kunt het beperkingen noemen, maar ook kaders noemen. Neem als voorbeeld Duplo. Je kunt met twee blokjes een huis maken, top! Gebruik je Lego, dan kun je in dat huisje ook een raam en deur zetten. En gebruik je een 3d printer, dan kun je elke organische vorm maken die je maar kunt bedenken.

Bedenk wel, dat bij een 3d printer moet je heel veel kennis zelf toevoegen. Hoe groot moet de deur precies zijn? Hoe dik moeten de muren zijn? Welk materiaal moet ik kiezen? Is het technisch wel mogelijk om een bedachte vorm te realiseren? Is bedachte oplossing wel brandveilig? Bij Lego weet je van elke bouwsteen hoe groot die is, in welke kleuren die beschikbaar is en wat de functie is. En wat scheelt is dat je op voorhand weet dat een Lego deurtje altijd werkt, want die als miljoenen keren getest.

En als laatste knuppel in het hoenderhok. Deze ontwikkeling van low code is al heel lang geleden begonnen. Wanneer heb jij voor het laatst een java library in je project geladen? Wanneer heb jij gebruik gemaakt van een of andere template engine? Sinds wanneer programmeer je object georiënteerd? Dit zijn allemaal hulpmiddelen om in plaats van assembly het programmeren naar een iets hoger abstractieniveau te brengen.
Mendix is een beetje te complex voor business engineer. Outsystems en Mendix zijn evenwaardig op dat vlak.
Ik heb intussen al echt zware projecten gezien met Mendix.
De grootste misvatting is vooral dat mensen denken dat dit high code moet vervangen. Terwijl het eerder complementair is.
Goed punt. Met focus bedoelde ik niet dat het al een 100% fit is. Als je objectief naar beide producten kijkt is OutSystems net iets toegankelijker voor een techneut. Die heeft daar iets meer mogelijkheden om onder de motorkap dingen aan te passen.

Zegt niet, dat je met Mendix dat niet kunt, maar het is iets moeilijker. Je kunt als je wilt gewoon de SDK aanroepen daarin allerlei aanpassingen doen, java toevoegen enzovoort.

Low code en high code zijn complementair, alleen moet de afweging juist zijn. Ik zou nooit Mendix gebruiken om een besturingssysteem in te ontwikkelen, of om een raket te besturen. Maar tegelijkertijd zou ik bijna geen reden weten om een administratief proces in php te ontwikkelen.
Maar je baseren op hoe goed je onder de motorkap dingen kan aanpassen wilt weinig zeggen over hoe goed het platform is.
Je lowcode platform schiet namelijk te kort als je onder de motorkap moet gaan.
Een zusterbedrijf van waar ik werk doet Mendix en zij doen echt wel zware projecten tegenwoordig.
Dit is het gewoon exact. Low code heeft een aantal sterke punten, maar die worden eigenlijk meteen overboord gegooid als je complete systemen er in gaat bouwen.

Als je hele development proces bestaat uit blokjes en lijntjes tekenen (ik bedoel dit niet negatief), waarom zou je dan met leed en moeite ook de low level werking van alles er in willen duwen.

Iemand heeft ooit een keer een van de blokjes gebouwd in een niet low code oplossing, dus waarom moet het daarna allemaal wel. Ik heb genoeg omslachtige niet praktische dingen gezien omdat het gewoon eigenlijk niet gemaakt was voor die zaken. Ja het werkte uiteindelijk, maar er was in 5 minuten een betere oplossing gebouwd in iets anders.

Maar anders om uiteraard ook zo, high level complexe processen in elkaar klikken gaat beter met low code.

Het leent zich uitermate goed voor processen tekenen, waarom moet de complete invulling daar van dan low code zijn? Bij ons is het ook vaak dat het daar op stuk loopt en er toch weer uitgeweken moet worden naar andere oplossingen. Alleen word het achteraf natuurlijk niet zo gecommuniceerd en blijft hogerop de indruk dat alles makkelijk en snel kan in low code.
Je hebt niet helemaal ongelijk.

Maar ik ben ontzettend blij dat er mensen zoals jij rondlopen.
Er is niks dat meer oplevert dan een bedrijf in nood helpen.

Ze bouwen hun hele hebben en houden, over hun, bij elkaar gesprokkelde excel sheets (want dat is waar we het over hebben).
En dan komt het een dag in 1x in elkaar zakken (niet _of_, nee wanneer), en dan bellen ze een profesional, voor veel meer geld dan goedkope beginnend developers gekost zou hebben.

Na 30 jaar in de business, ben ik wel een beetje imuun voor geworden "nu werkt low code wel hoor, we hebben het helemaal anders gedaan dit keer". Het enige positieve verschil wat ik zie op dat vlak dat het een boost zou kunnen geven is AI, maar ook dat is op het moment nogal shady of ronduit slecht, maar dat gaat wel vooruit. Dat kan "low-code" niet echt zeggen.

Je mag iedereen die het oneens is met je een purist noemen, ik hoop voornamelijk dat je bij veel bedrijven ingehuurd wordt voor advies! ;P
Niemand heeft gezegd dat goede software maken makkelijk is. Een prutser is in staat om een zelfrijdende auto tegen een boom aan te parkeren.

Het is jammer dat jij nog nooit een goede implementatie hebt gezien van een low code architectuur. Er zijn legio voorbeelden van kleine en grote bedrijven/organisaties die heel succesvol zijn met low code.

Het wel of niet eens met mij zijn maakt je geen purist. Wat je wel een purist maakt is als je gelooft dat alleen jouw vertrouwde java, python, ruby, mendix of outsystems de enige oplossing is voor alle problemen.

Waar jouw aversie van low code precies vandaan komt weet ik niet. Maar vergeet niet dat elk low code platform een oorsprong heeft bij developers dachten: dit ontwikkelwerk moet toch slimmer kunnen.
Vergeet dat business engineer maar, voor ontwikkeling althans. In de praktijk (als LC developer) zie ik met heel grote uitzondering wel eens iemand die daadwerkelijk iets bouwt bij klanten, maar het komt eigenlijk niet voor.

Een beetje applicatie is daar al snel te complex voor en daarnaast zijn mensen uit de business gewoon niet geinteresseerd, technisch voldoende onderlegd of beschikbaar voor zelf bouwen. Daar heb je toch IT'ers voor?

Citizen developers; mooie marketing term maar in de praktijk komt het eigenlijk niet voor. Wat wel een verschil is dat het platform zich veel beter leent voor kort cyclisch ontwikkelen, waarbij de gebruiker/klant direct in de feedback loop zit tijdens ontwikkeling en oplevering; aangezien vooral prototyping maar ook de ontwikkeling een stuk sneller gaat (vaak zelfs sneller dan de business het bij kan houden omdat ze de velocity niet gewend zijn ;P), speelt de business engineer hier wel een heel actieve rol. Maar bouwen.. misschien later met AI, maar nu nee.

Merk in het algemeen ook dat de complexiteit en mogelijkheden van LC vaak worden onderschat door collega IT'ers. De platformen hebben een gigantische ontwikkeling doorgemaakt en worden van, initieel vooral meer projectjes in de periferie van het IT landschap, steeds vaker voor core processen ingezet.
En niet alleen perse in de proprietary cloud van de vendor maar ook in private cloud in eigen containers of on prem. En inderdaad, los van of het altijd de juiste keuze is, je kunt eigenlijk voor ieder business process LC (Mendix in mijn geval) wel gebruiken. En die remaining 10% los je op met custom elementen in Java/JS of directe SQL calls als performance het verlangt.
Dat is ook mijn ervaring. Heb het echt nooit verder zien komen dan een demo / PoC.
Het doet mij altijd sterk aan ORM denken: iets dat ook nooit werkt behalve in de simpelste gevallen waar performance geen issue is. En dat zet eigenlijk door naar alle abstractie frameworks die overkoepelend willen zijn: die geven je de kleinste intersectie zodat eigenlijk niets werkt.
Ik ben overtuigd dat je low level code wilt hebben en tools om dat makkelijker te maken. Bij voorkeur simpele low level code: geen OO maar data oriented en plat. Ik zie dat in elk probleemdomein: abstracties falen, maar alles low level beschikbaar maken met tools erop om delen te genereren, dat werkt.
Tja met ORM zie ik toch vaak dat het probleem op de stoel zit dan aan de oplossing. Je kan in veel gevallen beide met elkaar combineren en kijken wat nodig is voor jouw use case.
Zoals alle frameworks/libraries moet je zien te begrijpen wat er gedaan wordt. Ga niet het wiel opnieuw uitvinden omdat je een library niet begrijpt.
Met de juiste orm's kun je vaak een goede combinatie maken, de eenvoudige queries in de orm, en de heel ingewikkelde of performance kritische dan in optimale (raw) sql. Dat is meestal de beste oplossing.
Dan heb je denk ik nog nooit bij grote bedrijven in de keuken gekeken. Om maar een voorbeelden te noemen: PostNL, ASML, Gemeente Rotterdam, Rabobank, Achmea, FMO, ESB, Siemens en diverse Rijksoverheid organisaties als RWS, COA, RIVM etc.

En dit zijn alleen nog maar een paar namen die actief zijn in het Mendix domein. En dat gaat echt verder dan demo/POC. Het betreft hele serieuze applicatielandschappen die heel veel full stack development oplossingen naar de eeuwige jachtvelden hebben gestuurd.

Ik zou je willen adviseren om je ogen verder te spreiden en echt goed om je heen gaat kijken. Iets verder dan je eigen bubbel op sourceforge, stackoverflow ;-)

Elke iteratie aan het front op low code is een reden voor bedrijven om daarvoor te kiezen.
Mijn kennis van Mendix is echt van lang terug, dus of het nog steeds op Mendix slaat weet ik niet. Maar in het algemeen zijn er een aantal zaken waar low-code, en iig destijds dus ook Mendix, een zwakte hebben:
- testbaarheid
- performance
- schaalbaarheid
en inderdaad zaken als het interne model omgooien.

Testbaarheid houdt in mijn geval in dat je met scripts kunt controleren of het systeem doet wat je verwacht dat je doet. Dit is belangrijk, omdat je dan kunt garanderen dat een nieuwe feature niet iets bestaands kapot maakt, of dat een bugfix niet gelijkertijd een nieuwe bug creëert. Ook helpt testbaarheid de goede werking te blijven garanderen als je de interne structuur intern moet omgooien (zie het laatste punt).

Performance betekent dat het systeem ook nog snel moet reageren als er veel mensen en/of andere systemen tegelijk gebruik maken van het systeem.

Schaalbaarheid betekent dat je eenvoudig meer of minder mensen en/of systemen kunt afhandelen door computers met dezelfde software ernaast te zetten of juist weg te halen. De software moet dan als het ware als één opereren (en blijven opereren), ondanks dat het uitgesmeerd staat (of wordt) over meerdere computers.

Het interne model omgooien is soms noodzakelijk omdat je met voortschreidend inzicht leert dat een bepaald concept wat je vanuit het bedrijf in je software hebt gemoduleerd zich net iets anders of indirecter tot een ander concept verhoudt als hoe je het initieel had bedacht. Of de wereld waarin het bedrijf opereert is simpelweg complexer geworden. Dan moet je dus gaan hermodeleren. Dat is sowieso lastig, maar met name met low-code oplossingen, is mijn ervaring.

Dat gezegd hebbende. Maatwerk software is altijd duur en op tijd zijn is soms belangrijker dan robuust zijn, dus ik kan me zeker voorstellen dat er toepassingen zijn te bedenken waarin het inzetten van een low-code framework een verstandige keuze kan zijn.
Yep. Ik heb er ook nooit mee gewerkt, maar kan wel voorspellen dat dat de problemen zijn aan de hand van wat ik de afgelopen 30 jaar aan "visual" tools heb gezien ;)

Het kan handig zijn in de niche van end-user-defined functionality. Denk aan een data report of visualisatie, dan zijn drag n drop tools zoals Tableau best handig. Maar ook daar moet (en kan) je niet verder gaan dan de basis: maar dat is ook niet de bedoeling voor end users.
Ik heb tot lange tijd voor (en met) Mendix gewerkt. Je opmerking over testbaarheid snijdt inderdaad hout, al is het niet zo dat het helemaal niet te testen valt, met Playwright, JUnit en API tests kun je een heel stuk afdekken.
Qua schaalbaarheid is het al een tijd lang zo dat je het aantal nodes waar je Mendix-app op draait probleemloos horizontaal kunt opschalen.
Het model omgooien (refactoren) daarvoor biedt Studio Pro (de IDE) best goede ondersteuning maar als jouw model spaghetti is dan wordt het lastig, in dat opzicht verschilt low code niet veel van high code.
Heb dezelfde ervaring, al meerdere demo's gehad en platformen geprobeerd, uiteindelijk is het heel eenvoudig om een formuliertje met een database te bouwen maar zodra je dan naar een iets uitgebreidere functionaliteit op het formulier is het meteen oh ja dat kan, maar dan moet je advanced aanzetten en dan kun je hier je code typen!

Ben zelf programmeur en ze promoten het dan altijd als iedereen kan het! Maar uiteindelijk is dat gewoon niet zo.
Zelfde met websitebouwer Wix. De eerste 10 pagina’s lijkt het te mooi om waar te zijn en bij de 11 kom je erachter dat dat ook zo is.

Maar voor management lijkt het een goede optie: dure programmeurs eruit, goedkope blokklikkers erin.
Heb je Mendix/Outsystems wel geprobeerd? Die zijn wel van een ander niveau dan Wix en dergelijke. De leercurve is dan ook wel een stuk steiler.
WordPress is een mooi voorbeeld van hoe low of zelfs no code een scala aan websites oplevert. Love it or hate it, het gros van de websites wordt tegenwoordig met WordPress gemaakt lijkt het wel en het ziet er allemaal prima uit. Dit concept moet volgens mij ook prima mogelijk zijn voor apps. Daarnaast zijn volgens mij de APIs van het OS zo mogelijk nog belangrijker dan de UI en dat kan natuurlijk prima in een low code pakket geïntegreerd worden.

[Reactie gewijzigd door watabstract op 14 november 2024 09:50]

Dat moet ik toch wat tegenspreken. Ik bouw ondertussen al bijna 15j applicaties met low-code, waaronder een aantal heel complexe. Het is echt maar sporadisch dat we naar high-code moeten teruggrijpen, en dan kan het ook gewoon. En als je het juiste platform/framework kiest, hoef je er helemaal niet rond te hacken, maar staat het helemaal open om dat te doen.
Ik heb ondertussen al wel heel lang opgegeven om high-coders proberen te overtuigen. Da's verloren moeite. Wel heel grappig dat die nu plots allemaal AI gebruiken om "code te genereren". Iets wat sommige low-code platformen waar ze zich zo tegen afzetten, eigenlijk al 20j doen.
Ik ben absoluut geen fan van low-code en meer specifiek Mendix, en wel om volgende redenen die ik in de praktijk zie:
- leuk dat je snel kan bouwen, maar heb je al eens nagedacht over het testen? Mendix heeft geen goede unit test tool. Er is iets van Mendix zelf, maar dat voldoet niet. Dan heb MTA, maar dat is eigenlijk geen unit test tool en prijzig. Als de cyclomatic complexity > 1, dan moet je unit tests schrijven.
Bij Mendix gebeurt dit niet in isolatie met mocks en stubs, maar altijd in een echte omgeving met een database eronder.
- Hoeveel keer schrijf je je code en hoeveel keer run je je tests daarop? Leuk dat het schrijven (misschien) eenvoudiger gaat, maar als het testen 10x moeilijker is, heb je niets gewonnen.
- de gegenereerde html code is vrij complex en ID's kunnen iedere keer veranderen. Lastig om goede automatische tests te schrijven.
- performance testen is nog een dingetje: de communicatie is zo complex, en wordt complexer, dat je met gewone load test tools niet kan correleren. Dan ben je bijna verplicht om naar duurdere load test tools zoals LoadRunner met TruClient of NeoLoad met RealBrowser waarbij je load zet via de GUI. Leuk, maar dan heb ik wel tientallen load generators nodig ipv enkele voor een paar honderd VUsers.
- en de laatste zal misschien gevoelig liggen, maar low-code tools (dev of test), trekt personen aan die de basisprincipes niet onder de knie hebben. Dat gaat van het niet weten wat unit tests zijn, niet begrijpen waarom die testers om die ID's vragen, zeer grote 'macroflows' bouwen ipv kleine geisoleerde macroflows en fouten tegen security die continu begaan worden. De Devs weten enkel wat zij aan de voorkant erin steken, maar niet hoe het er aan de achterkant uitkomt. Als een tester daar dan vragen over heeft, kunnen ze nergens terecht met hun vragen.
Edit: In dat opzicht ben ik het helemaal eens met de titel van de talk ‘Low-Code: A fool with a tool is still a fool’. Echter lijkt low-code vaak veel zij-instromers aan te trekken. (Fools zou ik hen niet willen noemen)

[Reactie gewijzigd door Chris_147 op 14 november 2024 08:28]

Kleine aanvulling/correctie op je verhaal: je kunt elk UI-element een voorspelbaar name attribuut meegeven en daarmee automatische tests schrijven. Met bijv. Playwright werkt dat goed.
Zeg ik ook in mijn reactie hieronder.
Het is echter iets wat ontwikkelaars extra moeten doen en gebeurt het niet altijd of zelfs vaak niet.
Fijn dat iemand niet alleen naar de outpunt/voorkant kijkt, maar ook naar de "testability". De opgeleverde HTML is vaak bagger met onbruikbare class en ID namen, die vaak ook dynamisch zijn. Gevolg: de applicatie is alleen handmatig te testen, omdat geautomatiseerde tests niet stabiel zijn te krijgen. Uiteindelijk funest voor de time to market en/of quality to market.
Uiteindelijk kan het wel, maar de ontwikkelaar moet dan specifiek een uniek attribuut toevoegen. En dat hangt af van de volwassenheid van de ontwikkelaars en die valt nog wel eens tegen bij low-code. Want "extra werk", "testen is niet voor ons", ...
Een attribuut zou bij dit soort tools automatisch toegewezen moeten worden op basis van eigenschappen of context, zodat het testen ook automatisch gaat.
Eens, maar in de praktijk gebeurt dat vrijwel nooit, zit niet in de mindset van de meeste ontwikkelaars en is vaak ook geen onderwerp van bv user stories of definition of done.
Ik heb die Magic Quadrant is opgezocht en wat mij opvalt is dat er alleen maar commnerciele partijen opstaan. Hoe zit het dan met open source lowcode oplossingen? Veel bedrijven die Industry4.0 of IIoT tot hun software oplossing willen aanbieden maken hier juist gebruik van. denk dan aan Node-Red als voorbeeld.

Een vraag uit eigen interrese voor andere lezers, hoe zien jullie het gebruik van een commerciele low-code VS. een open source oplossing?
Je moet (flink) betalen om in een Gartner Magic Quadrant opgenomen te worden. Je hebt zelfs invloed op de positie. Het is niks anders dan een duur marketing tool.
Volgens mij is er nooit echt bewijs geweest voor dat je Gartner moet betalen om in Magic Quadrant te komen en Gartner ontkent het ten stelligste. De doelgroep voor Magic Quadrant is wel grote partijen die een complete oplossing (inclusief support e.d.) zoeken. Er staan wel open source partijen in Magic Quadrant maar dat zijn dan over het algemeen wel open source partijen met een commerciele en enterprise gerichte insteek.
Bij BNR zijn de journalistieke programma’s ook “volledig los” van de sponsoren van podcasts. Maar…als je sponsor bent van een podcast dan heb je wel meetings met journalisten “zodat ze je beter leren kennen”.

En zo werkt dat overal.
Ik heb ook nooit begrepen waarom mensen nog naar die Gartner rapporten kijken. Echt de boel voor de gek houden.
Wij gebruiken Appsmith als low-code tool om interne web applicaties te maken (de opensource versie) en dat werkt redelijk goed.

Commerciële oplossingen (zoals Outsystems bv) zijn heel duur, en dus duidelijk gericht op grote organisaties. Daar zitten dan ook alle toeters en bellen in, inclusief support .. en de nodige consultants vermoed ik.. ;-)

Onze ervaring met Appsmith:

- We gebruiken dit om interne tools te maken, zoals een support tool waarin data kan opgezocht worden en instellingen kunnen aangepast worden door 1st line support
- Ontwikkeling gaat vrij snel, met "click-and-drop", data wordt opgehaald met SQL queries, aanpassingen gaan via SQL of API endpoints
- De output is een web app met SSO (Google in ons geval)
- Voordelen: snelle ontwikkeling, goede performantie, veel mogelijkheden, git integratie
- Nadelen: niet responsive, soms wat clunky (bv bij het kopiëren uit een tabel), charts trekken op niet veel
Het "tooltjes" bouwen zie ik ook nu als enig voordeel.
Ja dat klopt. Een poc of commerciële app zou ik er nu ook niet bouwen. Outsystems en dgl wordt daar ook weinig voor gebruikt, lijkt me..
Ik ben een fervent high coder, maar ben het laatste half jaar in aanraking gekomen met low code (OutSystems). Hoewel ik het liever niet toegeef, denk ik dat high code talen voor web/mobile applicatiedevelopment hun borst nat kunnen maken. Een run-of-the-mill web of mobile applicatie bouw je in een low code platform zó veel sneller, dat is gewoon niet grappig meer. Wel heeft low code net als high code een gedegen software architectuur en een doordacht datamodel nodig - ik denk dat citizen development flauwe kul is. In sommige low code platforms missen nog wat zaken (unit testing, branchingmodel, etc.), maar het is een kwestie van tijd voordat dat er ook in zit.

Ik denk niet dat de high code talen voor applicatiedevelopment gaan verdwijnen, ze gaan alleen flink wat marktaandeel inleveren: als je als club een low code platform hebt, kun je daarin al je webapplicaties bouwen, en gebruik je high code alleen nog maar voor specifieke backends. Bijv. als je een custom planningalgoritme moet implementeren, of als je moet interfacen met een systeem via een custom protocol op een TCP socket, dat soort dingen.

Neemt niet weg dat high code nooit weg zal gaan: er zijn genoeg gebieden waar low code nooit goed in gaat zijn, zoals ontwikkeling van besturingssystemen, games, device firmware. In vakgebieden als data science denk ik dat low code wel veel zou kunnen bieden, maar vraag ik me af of je er ook daadwerkelijk sneller mee zou zijn dan met Python of R.

Mijn hoop is dat er de komende jaren een volwassen open source low code platform ontstaat. Een van de dingen die me het meeste tegenstaat aan OutSystems is hoe gesloten het allemaal is, en hoe weinig resources je online vindt.
Ik zou unit testing (of testing in het algemeen) niet onderschatten als "gemiste zaken".

Dit zijn prima tools om snel tot 80 of 90% van je applicatie te komen, maar daarna loop je al snel vast en heb je meer hulp nodig die in veel gevallen duurder is. En als je vast zit aan een platform, dan kunnen de kosten ook vrij snel stijgen, zeker als je door gebrek aan goede tests, ineens veel dataverkeer krijgt.

Ik hoop ook op meer volwassen open source platformen, maar ik denk niet dat we daar al zijn. Vooral als de platformen alles en iedereen moeten bedienen waarbij geen nee kan worden verkocht.
In sommige low code platforms missen nog wat zaken (unit testing, branchingmodel, etc.)
Zijn die zaken niet absoluut essentieel?
Als je dat niet gebruikt waar ben je dan mee bezig als ontwikkelaar?
Mijn grootste bezwaar tegen low-code platforms is de vendor lock-in. Ik werk als webdeveloper en de snelheid waarmee je met low-code aan de slag kunt is echt wel verleidelijk, maar ik wil niet vastzitten aan een commerciële partij wat plots z'n prijzen kan verhogen, een andere route kan inslaan etc.

Ik heb een tijdje terug geëxperimenteerd met Amplication voor backend-development voor het web; een low-code platform wat high-code genereert op zo'n manier dat je zelf wel de volledige controle houdt. Werkte prettig, maar nog niet perfect. Inmiddels gebruik ik Supabase voor de backend van projecten wat nog beter voldoet. Dat genereert geen code, maar is een schil om PostgreSQL heen waardoor ik alsnog geen vendor lock-in heb.

Weet men hier misschien van soortgelijke platforms/frameworks maar dan voor de frontend? Wij ontwikkelen nu alles high-code in Angular, maar ben zeker geïnteresseerd in low-code oplossingen die me wel alle controle en vendor freedom geven.
Alhoewel je er natuurlijk niet in één keer je model mee kunt omzetten naar een ander framework, biedt Mendix wel de Model SDK aan waarmee je je hele model programmatisch kunt uitlezen en exporteren. Dus van een totale vendor lock-in is geen sprake.
Mendix is duidelijkj druk bezig met marketing. :+ Ongeveer een jaar geleden iets mee gedaan. Het ws toen een soort zwitsers zakmes waar eigenlijk alles wat er aan/op zat net niet helemaal dat was wat je nodig had. Voor de relatief simpele flows is het echt de perfecte tool. Maar zo gauw je meer wil kom je al snel in de knoop zoals @Zoijar al aangaf

[Reactie gewijzigd door Webgnome op 14 november 2024 08:24]

Ergens wel wat opmerkelijk dat je 300 eur mag betalen om een marketing praatje bij te mogen wonen... :+
Terrie Titelspecialist Tweakers @Zoijar14 november 2024 10:10
We proberen meerdere aspecten op de Developer Summit aan bod te laten komen. Daarbij weten we ook dat veel bezoekers geen fan zijn van Low-code, maar vinden we het toch goed om dit onder de aandacht te brengen. Mede ook om de discussie die we hier in de comments al los zien barsten, door hier samen over na te denken komen vaak de mooiste inzichten.
Ik zeg nergens dat Mendix of vergelijkbare tools niet thuis hoort op een dergelijk event. Het lijkt mij juist een goed idee om niet alleen maar hardcore dev dingen te laten zien. Low code kan in een boel scenario's echt wel een oplossing zijn.

[Reactie gewijzigd door Webgnome op 14 november 2024 10:11]

Salesforce ea. doen niet anders :+
Met een paar jaar vraag je chatgpt om een app te schrijven.
Lijkt me op langere termijn zeker een dreiging voor low-code oplossingen. AI-Code heeft echter, iig op dit moment, vaak weer een andere zwaktes, namelijk:
- securirty
- over complexiteit
- overtuigend, ook als het er compleet naast zit

AI leert immers van het internet, en daar wordt juist vaak een bepaalde complexiteit op conceptueel niveau uitgelegd.
AI code generatie lijkt me op dit moment dus geschikter voor mensen met technische achtergrond dan mensen zonder technische achtergrond, en dat is precies niet de markt waar low-code zich nu op richt.
Daarom zeg ik ook over een paar jaar. Ai zal talen beter begrijpen, en dan spuugt het gewoon kant en klare programmas uit.
Dit is echt niet een bedreiging voor enkel low code, dit is een bedreiging voor de gehele IT sector.

Als je je baan veilig wilt stellen, dan moet je zelf gaan schrijven aan de AI oplossingen. Immers, die ene java functie kan AI ook schrijven. Het netwerkbeheer kan ook door AI gedaan worden. Automatische testen kunnen ook gemaakt worden door AI. Het schrijven van business requirements, het grootste deel kan al gedaan worden door de AI.

AI is de volgende stap van applicatie ontwikkeling. Dus als je nu nog niet gewend bent aan low code, hou dan je hart maar vast.
En je zit vaak vast aan de tool, stel dat Mendix de licentiekosten enorm verhoogd, dan zit je vast en kan je niet zomaar over naar iets anders.
Zelf heb ik Mendix uitgeprobeerd, maar het was niet voor mij. Nu ontwikkel ik met behulp van PowerApps en daar is veel in mogelijk. Het grote voorrdeel is de ontwikkelsnelheid, zeker wanneer je weet wat je doet is een interface bouwen en dergelijke (visuele) elementen heel snel, net als out-of-the-box data koppelingen. Ook de performance en dergelijke is zeker acceptabel, waarbij je direct op een tablet, telefoon en via het web kunt benaderen. So far so good, het heeft echt wel mogelijkheden.
Die mogelijkheden komen echter met meerdere nadelen. De belangrijkste die ik zelf vindt is dat het makkelijk te gebruiken is. Daar zit een grote valkuil in, ik kan in vijf minuten een werkende app maken die nergens op slaat. Iets wat ik regelmatig zie gebeuren. Het werkt en het ziet er acceptabel uit dus publishen maar en gaan. Ondertussen gebeurd er op de achtergrond van alles, ook in de data, wat helemaal niet de bedoeling is. Kortom, je maakt iets snel in elkaar en als je niet uitkijkt maak je ook snel iets kapot.
Documentatie - daar is een gebrek aan. Je kunt niet goed/makkelijk documenteren binnen applicaties. Zelf heb ik hier wel behoefte aan en zie ik gewoon als een nadeel (bij veel pakketten overigens).
Je kunt teveel zaken koppelen; ook hier geldt weer dat je moet weten wat je doet. In PowerApps kun je bijvoorbeeld Power BI rapportages en Power Automate makkelijk integreren. Dat werkt, maar met de complexiteit van sommige processen kun je ook heel snel de fout in gaan. Wanneer je afwijkt van standaard elementen gaat de leercurve stijl omhoog, ook bij Mendix toen ik het probeerde.
De marketing doet mensen geloven dat je er alles mee kan en daar zijn managers nogal gevoelig voor. Zo kreeg ik laatst het verzoek of ik niet "even" AFAS kon nabouwen in PowerApps, dat scheelde licentiekosten. Iedere tool, ook lowcode, heeft zijn nut en zijn doel, maar dit goed communiceren is marketingtechnisch vaak discutabel want ja, er zouden dan minder sales kunnen komen.
De marketing maakt het simpel, het is simpel in beginsel, maar dat maakt het geen simpele tool die iedereen kan gebruiken - ondanks dat het zo wel wordt vermarkt. Het is voor veel zaken een oplossing, zeker als het gaat om relatief eenvoudige applicaties. Bij uitstek heel geschikt. Wil je een AFAS achtig systeem maken of andere complexe softwarepaketten "nabouwen", dan zou ik nog eens drie keer achter de oren krabben alvorens daar ja op te zeggen.
Kortom, lowcode heeft zeker meerwaarde, vooral bij simpele tot gemiddelde applicaties die relatief recht toe-recht aan zijn, maar complete oplossingen van andere pakketten nabouwen of andere complexe zaken is een brug te ver (en dat is niet erg).
Anthony is van plan om een demo te geven waarin hij de Tweakers event-app nabouwt met behulp van low-code. Hij wil laten zien hoeveel (of hoe weinig) tijd het kost om het tastbaar en praktisch te maken voor het publiek.
Dit zou pas realistisch zijn als hij op het moment zelf een app voorgeschoteld krijgt. Tijd zit namelijk zelden in het typen/klikken van code/blokken zelf, meer in de juiste oplossing vinden voor je probleem.

Low code kan best zinnig zijn. Maar laten we het wel puur en eerlijk houden.

[Reactie gewijzigd door BartOtten op 14 november 2024 11:28]

Op dit item kan niet meer gereageerd worden.