Low code kan reducere udviklingstiden til det halve, viser undersøgelse

Hvor mange herinde mener at Word og Excel makroer er guds gave til menneskeheden ? Det er low-code i en form. Det ender med ikke at være vedligeholdt, det ender med at gå i stykker, og da det er lavet af personer uden uddannelse, så er det ustruktureret og svært for en ny person at sætte sig ind i.

Der er andre low-code ting der er lettere, IFTTT og lignende, hvor man bruger komponenter til at flytte/behandle data fra forskellige systemer. Og det er smart, sålænge high-code komponenten til low-code stadig er kompatibel og fungerer. Når komponenten ikke længere fungerer, så har man et problem.

Low-code er godt til mange simple flows, men det er vigtigt at man tænker lifecycle ind hele sit low-code, herunder også maintenance/support af de komponenter der anvendes.

Jeg tror man bliver nødt til også at se low-code i den kontekst, at de kan være med til at rydde op i al den skygge-it der er derude.

It-afdelinger kan stille en programpakke til rådighed for virksomhedens ansatte, hvor de så kan bygge de små applikationer, som de enkelte afdelinger har brug for. Fordelen for IT er, at der er fuld kontrol man hvilke apps der bliver bygget, og der er fuld kontrol over brugeradministrationen.

Fordelen for de ansatte er, at de ikke længere løber panden mod en mur, når du dukker op med deres småprojekter, som IT afviser.

Det har jeg skrevet lidt mere om her

Det er klart, at low-code i sig selv løser alle verdens problemer, for selv om man hurtigere kan bygge sin applikation, er der stadig behov for en ordentlig governance.

Ja, jeg må indrømme, at jeg har puttet low-code og no-code i samme kasse - i øvrigt samme kasse som MS Access og Excel (alt efter anvendelse). Det har jeg gjort, fordi de har det tilfælles, at de ofte bliver brugt til at få noget ud over rampen i en fart.

Hvilket bestemt kan have sin berettigelse, eksempelvis til prototyper, start-ups, der skal hurtigt i gang uden at investere en masse eller til små løsninger, der bare skal løse én bestemt opgave.

Jeg synes bare, at man skal passe på med at anse det som som nye superværktøjer, der principielt og i al fremtid kan spare nogen for en hel masse.

Jo, jeg vil da gerne bruge mere tid på non-trivielle opgaver, men det har low-code løsninger ikke gjort noget ved - tværtimod er der gået meget god tid med at forsøge at udrede nogle problemer, som en løsning, lavet af ikke-IT-kyndige, har skabt. Den tid ville jeg da hellere have brugt på at lavet en sund løsning, som kunne gøre en rigtig forskel for firmaet.

Og når jeg siger "sund løsning", kunne det såmænd godt være Excel/Access eller en online-løsning eller noget helt tredje. Man skal bare gøre sig klart, at træerne ikke vokser ind i himlen; man skal vide noget om datasikkerhed, sætte sig ind i det valgte produkts opdateringer osv. - alt det IT-tekniske, men ikke mindst - være parat til at smide hele løsningen over bord og starte forfra, når kravene og behovene har ændret sig mere end løsningen kan klare.

Jeg faldt over denne artikel:https://stackoverflow.blog/2021/06/09/using-low-code-tools-to-iterate-products-faster/

Han er overvejende positiv, men kender også faldgruberne.

Eet sted hvor jeg synes no-/low code giver rigtig god mening, er når man laver prototyper til at demonstrere et workflow, f.eks. i forbindelse med tidligere user reviews. Her giver det god mening at lave en applikation som ikke bare viser en arbejdsgang gennem skærmbilleder (Xd, Figma, Sketch), men i stedet faktisk har en egentlig funktionalitet implementeret, specielt hvis funktionaliteten er kompleks. Her er det ikke væsentligt om applikationen har et højt robusthedsniveau, men udelukkende at den viser de detalje-opførsler man ellers ikke får demonstreret. Jeg har ikke førstehåndskendskab til add-on produkterne, så jeg kender ikke kvaliteten, men der findes low code-systemer til de nævnte skitseværktøjer, f.eks. Bravo til Figma.

Jeg synes, det er en interessant debat, men også at der mangler lidt forståelse for hvad Low-Code egentlig repræsenterer - for selvom Gartner mv. prøver at putte det i én kasse, er der stor forskel på de forskellige virksomheders tilgang til emnet. Fx er Low-Code og No-Code samlet i én kasse, men fokuserer på forskellige målgrupper.

No-code repræsenterer i høj grad en tro på, at vi kan lade forretningen (læs non-developers) overtage en stor del af udviklingen. Low-Code fokuserer i højere grad på at gøre den professionelle udvikler mere effektiv –samtidig med at forretningen kan være en mere aktiv del af udviklingsprocessen.

Det er absolut en påstand, men jeg tror på, at 80/20 reglen ikke er helt ved siden af her – og 80% af arbejdet, som 80% af udviklere bruger tid på, er trivielt arbejde relateret til CRUD, beskrivelse af processer via if/else/switch-sætninger, og lave front-end arbejde som de ikke nødvendigvis er verdensmestre i.

Og ærligt talt; hvem ønsker ikke at være mere effektiv på dette punkt, så mere tid kan blive brugt på de sidste 20% af opgaverne, som er non-trivielle, og udfordrer os mere? At vælge en Low-Code platform er ikke et "enten/eller", men et "både og", hvor håndskreven kode stadig har sin berettigelse i bestemte tilfælde - hvilket platformen bør tillade.

Derudover giver det visuelle miljø man arbejder i, i et Low-Code-værktøj mulighed for at forretningen, de sande domæneeksperter, kan indtage en større rolle. Fx kan de visuelt validere og bidrage til, at en proces agerer som forventet, da det ikke kræver andre skills end at man kan læse et procesdiagram. Ligesåvel som vi ikke tror på forretningen kan kode ligeså godt som os - må vi også erkende at vi aldrig opnår det samme domænekendskab, selvom vi alle kan, og bør, nærme sig hinanden i en samarbejdende proces.

I sidste ende tænker jeg, at det kommer ned til 2 typer af udviklere – dem, der er fokuseret på at levere værdi til forretningen hurtigst muligt, og dem, som arbejder i branchen pga. de personlige udfordringer, og hele tiden skifter deres fokus til det seneste nye framework eller teknologi, de kan tilføje CV'et.

Og så ender man med at IT-afdelingen bliver flaskehals. I stedet bør man uddanne organisationen til god IT hygiejne og placere ansvaret så tæt på dem der har ansvaret for forretningsprocessen som muligt.

Helt rigtigt; IT-afd. er ofte en flaskehals, men så burde man give den lidt mere manpower + opbygge en kultur, hvor IT-afd. ikke bare bliver tænkt som dem, der sørger for stabilt internet, hardware og support - og ikke andet.

De fleste IT-folk jeg kender, kan godt sætte sig ind i forretningens processer. Og du har helt ret; IT-afd. skal ikke være små konger og der er mange aspekter af IT, hvor alle i virksomheden har et medansvar.

Det jeg mener er, at man bør snakke med IT-afd., inden man kaster sig ud i et eller andet. Og selvfølgelig skal IT-afd. lytte. Man skal bruge hinanden som sparringspartnere. Nogle er eksperter i forretningen, andre er eksperter i IT :-)

@Sune: helt rigtigt. Low-code, RAD mv. kan sagtens have sin berettigelse.

Det skal bare gøres rigtigt.

Jeg synes egentlig ikke problemet ligger i selv sproget, uanset abstraktionsniveau. Problemet ligger i, at det nogle gange lyder som om, at "konceptet" (low-code) indbyder til, at hvem som helst kan lave en løsning i en ruf og så er vi videre med hverdagen.

Det kan man også - men det ender bare ofte i de førnævnte problemer.

Script sprog blev introduceret? - hvad....? Er det ikke engang compileret på forhånd?

Hov hov hov ... script sprog er en evolutionær blindgyde!

Mere seriøst: Scriptsprog ændrer ikke ved abstraktionsniveauet.

Alle løsninger - store som små - burde vendes med IT-afd.: - fordi man i afdelingen kan hjælpe med, hvad der skal tages af beslutninger vedr. datasikkerhed, backup, pladsmangel, rettigheder osv.

Og så ender man med at IT-afdelingen bliver flaskehals. I stedet bør man uddanne organisationen til god IT hygiejne og placere ansvaret så tæt på dem der har ansvaret for forretningsprocessen som muligt.

I stedet for at IT afdelingen står som små konger der kan dømme ting inde og ude, så bør IT i stedet hjælpe resten af organisationen til at forstå risici. Det vil sige ting så som backup, sikkerhed, pålidelighed. Og når den så får brug for "rigtig" IT så kan vi dukke op med alle de rigtige værktøjer i værktøjskassen.

Hvis man fx. tager sikkerhed, så er en af de største fejl virksomheder og myndigheder begår netop at tro at man kan parkere ansvaret for sikkerhed i en afdeling. Sikkerhed er alles ansvar. Alle skal ønske sikkerhed. Alle skal opsøge viden og ekspertise om sikkerhed. Det betyder ikke at alle skal være eksperter i sikkerhed. Ligesom en række andre aspekter når det handler om at drive en virksomhed.

Min erfaring er, at man før eller siden ender med at erstatte den slags løsninger med noget mere prof. alligevel - og så kunne man lige så godt være startet der.

Det lyder som om der er mange kritiske røster omkring et nyt abstraktionsniveau.

Mon ikke der var samme kritik da:

Assembler blev introduceret?

• hvad...? skal vi nu ikke lave det direkte i Hardware?

C blev introduceret?

• hvad...? skal vi nu blot antage den kan lave ordentlig assembler?

C++ blev introduceret?

• hvad....? Er vi nu sikker på den kan styre pointere ordentligt?

Script sprog blev introduceret?

• hvad....? Er det ikke engang compileret på forhånd?

Er dette ikke blot det næste led i kæden? Vi laver mere og mere komplekse løsninger, det er fint at vi får endnu et værktøj i kassen.

@Michael: du har ret i, at nogle gange kan "godt nok" være bedre end ingenting; især hvis man har ventet alt for længe på en løsning. Men vælger man at gå den vej, skal man være skarp på, at løsningen gennemgås og evt. opdateres til en mere prof. udgave i nær fremtid eller måske ligefrem erstattes af noget, hvor man har styr på tingene. Og hvem skal så sørge for, at det sker? Næppe den pågældende hobby-programmør, da han/hun som regel har andre arbejdsopgaver.

Som Sune påpeger, så kan de små løsninger få vokseværk - det gør de ofte; der skal lige en feature mere på, der skal data ind fra en anden database el. lign. Og dermed begynder tingene at sejle:

Problemet er når løsningerne vokser sig for store, eller de viser sig at være decideret forretningskritiske. Lige pludselig er Knud ikke i biksen længere, eller den ene maskine skuffeløsningen var på crasher, eller Jesper kommer til at gemme en version der ikke virker (og hov, version control? Hvad er det?).

Alle løsninger - store som små - burde vendes med IT-afd.:

• fordi man i afdelingen kan hjælpe med, hvad der skal tages af beslutninger vedr. datasikkerhed, backup, pladsmangel, rettigheder osv. Og - ikke mindst - at nogen skal kunne supportere løsningen fremadrettet, så staffetten ikke bare bliver smidt i samme øjeblik programmet er færdiglavet.
• dels fordi både IT-afd. og ledelsen har en bedre chance for at få øje på behovene i organisation
• dels fordi IT-afd. og ledelsen er dem, der kan få øretæver pga. datalæk, ringe sikkerhed mv. Det dem, der bliver trukket igennem et audit af og til og ikke sælgeren, kontorassisten eller ingeniøren.

Low-code, RAD-værktøjer og lignende shake-and-bake ting kan være helt ok. Men der skal være styr på processen. Min erfaring er, at man før eller siden ender med at erstatte den slags løsninger med noget mere prof. alligevel - og så kunne man lige så godt være startet der.

Hvis man finder det rigtige abstraktionsniveau så kan amatør-udviklere lave rigtigt fine løsninger. Fx. er Excel (uden VBA) et fantastisk værktøj hvor folk uden IT uddannelse kan bygge komplekse beregninger. Også selvom man kan skyde sig selv i foden og selvom der er en hel del man ikke bør forsøge.

I mit studiejob hos PestDanmark (som intet havde med udvikling at gøre) fik jeg flikket noget Excel + VBA sammen som sparede produktionslederne for en del tid. De havde noget daglig statistik i HTML-format som de godt ville Excel'e videre på, og den eneste måde de havde at bære det over var manuelt at vælge de rigtige elementer i Internet Explorer og så copy-paste. Ikke "select all", men starte det rigtige sted, træææææææække musen i lang tid, og stoppe det rigtige sted. Den manuelle select-operation tog noget tid, og selve copy/paste operationen var også ret langsom, det var en stor mængde data, gammel IE, sløve maskiner.

Med VBA kunne jeg snuppe lave et kald og få fat i HTML'en, strippe de første M og sidste N characters, og den interessante mængde var ren nok HTML til at kunne parses med hvad der nu var tilgægenglig af XML COM objekt, derefter lidt massage, og så spyttes ud fornuftigt i regnearket.

Det havde garanteret været svinedyrt at få bygget en rigtig løsning, om det så var det rapportering de havde brug for, eller bare en export til csv, så den arbejdsaften hvor jeg egentligt ikke lavede det jeg var ansat til var givet ret godt ud.

Problemet er når løsningerne vokser sig for store, eller de viser sig at være decideret forretningskritiske. Lige pludselig er Knud ikke i biksen længere, eller den ene maskine skuffeløsningen var på crasher, eller Jesper kommer til at gemme en version der ikke virker (og hov, version control? Hvad er det?).

Både Low og No-Code værktøjer kan have deres eksistensberettigelse, men det er en delikat balance.

Sidenote: hvor ofte sker det at kunder ser en demo/prototype, og derefter har svært ved at forstå at "den sidste mængde udvikling" der skal til for at have noget produktionsmodent er ret omfattende? :-)

Fint nok til prototyper og små løsninger...
...men der er altid nogle "rigtige udviklere" der ender med at skulle rydde op, når det gror for stort og ambitiøst.

Hvis man finder det rigtige abstraktionsniveau så kan amatør-udviklere lave rigtigt fine løsninger. Fx. er Excel (uden VBA) et fantastisk værktøj hvor folk uden IT uddannelse kan bygge komplekse beregninger. Også selvom man kan skyde sig selv i foden og selvom der er en hel del man ikke bør forsøge.

Bare fordi jeg i nogen grad kan betjene hammer og sav, betyder det ikke, at jeg er lige så god til at renovere soveværelset som en god håndværker ville være. Og resultatet bliver ikke bedre, fordi jeg går over til batteridrevet værktøj; manden med uddannelse, erfaring og know-how vil altid vinde.

Men der er rigtigt mange steder hvor vi ikke har brug for den fantastiske håndværker. "Godt nok" er bedre end ingenting. Sådan er det også med IT. Jeg mener det er helt fantastisk at almindelige amatører kan lave rigtigt meget selv. Vi bør stræbe efter at skabe udviklingsværktøjer med det rette abstraktionsniveau sådan at mange løsninger kan bygges af amatører. Så har vi i særklasse revolutioneret verden.

Jeg kan godt være lidt bange for, at low-code værktøjer kan være med til, at der blomster nogle elendige software løsninger op.

Tjaa ... men hvis der kun er en der kører af sporet for hver 10 der dukker op, så er det sandsynligt en success. Der er masser af steder i dag hvor vi har manuelt arbejde fordi det er for dyrt at bygge en IT løsning der løser opgaven. Der hvor det går galt må vi starte forfra.

Det er lidt underligt, at netop faget programmering i den grad har været - og stadig bliver - betragtet som noget, man sagtens kan excellere i uden alverden af uddannelse eller erfaring, hvor det bare er et spørgsmål om at have det rigtige udviklingsværktøj.

Bare fordi jeg i nogen grad kan betjene hammer og sav, betyder det ikke, at jeg er lige så god til at renovere soveværelset som en god håndværker ville være. Og resultatet bliver ikke bedre, fordi jeg går over til batteridrevet værktøj; manden med uddannelse, erfaring og know-how vil altid vinde.

Jeg kan godt være lidt bange for, at low-code værktøjer kan være med til, at der blomster nogle elendige software løsninger op.

Her i firmaet havde vi engang en masse små løsninger rundt omkring; det var mest Excel-ark, med og uden makroer, samt enkelte Access-løsninger. Bevares, de fungerede, men den slags skygge-IT ville vi godt være fri for. Det var ikke til at sige, hvad der pludselig ikke fungerede, hvis man opdaterede en SQL-server eller flyttede et netværksdrev til en anden filserver.

Ikke mindst var det umuligt at sige, hvem der havde adgang til hvad. Selvfølgelig kan man gøre noget med rettigheder på databaser og netværksdrev, men hvis man fjerner et værtøj fra folk, bliver man også nødt til at give dem et nyt, hvis de skal kunne arbejde.

Så det har været en proces at fjerne små hjemmelavede løsninger og erstatte dem med noget, hvor der er mere styr på, hvad programmet gør, hvordan det bliver opdateret og ikke mindst rettigheder.

Det betyder ikke, at der ikke kan være brug for små værktøjer til det ene eller det andet. Om det så bliver lavet med et eller andet low-code værktøj eller bliver programmeret i C, er i princippet mindre vigtigt - det vigtige er, at der er styr på udviklingen, at programmet gør det, man forventer og ikke mere, at der er styr på rettigheder osv.

Men jeg har flere ting i mod den slags værktøjer, der lover hurtige resulter, uden at man behøver at kunne kode (ret meget):

• De er for ufleksible. De kan bruges til en del, men rammer for ofte en begrænsning, hvor man alligevel bliver nødt til at kunne programmere rigtigt - og så ender løsningen med at blive en underlig bastard, hvor man ikke rigtig stoler på stabiliteten.

• Fejlfinding og ansvar. Hvis noget går langsomt eller laver fejl, hvor ligger problemet så - i løsningen, i databasen, i forbindelsen ...? Hvem skal fejlsøge og få det til at virke igen? Efter min erfaring ender det altid med, at IT-afdelingen skal udrede trådene, selvom de ikke har haft noget med den pågældende løsning at gøre. Og det kan der gå meget god tid med...

• Den lette tilgang får nogle brugere til at tro, at de godt kan udvikle IT-løsninger - og det gør de så, uden at vende det med IT-afdelingen, hvilket kan ende med at give flere problemer; mere skygge-IT, datalæk, korrupt data osv. Det bliver ikke bedre af, at de via diverse google- og youtube-søgninger får sig noget know-how - lige præcis nok til at blive farlige.

...men der er altid nogle "rigtige udviklere" der ender med at skulle rydde op, når det gror for stort og ambitiøst. Og hvis det har fået lov til at simre for længe, kan det være et rigtigt nasty stykke arbejde.

Det er svært at finde balancen der giver nok funktionalitet til at lave gode, mindre værktøjer... uden at give en lillefinger for meget, så det ender med uvedligeholdbare Frankensteinløsninger.

I midt halvfemserne turnerede Sun rundt i en bus og demo'ede "grafisk" programmering. Forbind en slider med et tal felt feks. Til demo var det sjovt, i praksis uanvendeligt. Siden har der været en lind strøm af lignende værktøjer.

Det er endnu ikke endt med en vinder.

Hver gang nogen har annonceret at business analytikere kunne udvikle via no-code, så er det endt i hænderne på rigtige udviklere alligevel.

Jeg har endnu til gode at se en enterprise løsning, hvor man stoler på den slags.

https://web.archive.org/web/20190501184114/https://devopsagenda.techtarget.com/opinion/Why-the-promise-of-low-code-software-platforms-is-deceiving

(Fundet via https://en.wikipedia.org/wiki/Low-code_development_platform#cite_note-16)

»En leverandør skrev en løsning på 48 timer og solgte den til omkring 25 regionale banker. Så de kom ind på et helt nyt forretningsområde på to dage. Og så kunne bankerne selvfølgelig tilrette løsningen,« udtaler analytikeren til SD Times.

Javel ja - sjovt løsningen og bankerne ikke er navngivet, ikke?

(Men husk lige at tjekke afsenderen! ...

ServiceNow er en point & click cloud platform framework , som bl.a. kan sættes op til at klare mange processor og er rimelig customercerbar - men at kalde det "low code" er "billigt" sluppet. Systemet kan det det er lavet til og kræver meget kode, hvis man ikke vil følge den tankegang eller bare vil have noget der er mere avanceret en simple dagligdags løsninger.

I mit første job i branchen arbejdede jeg med Navision. Der kunne en revisor eller excel-haj komme på et 3 dages kursus og når han gik derfra kunne han lave fine tilretninger til den eksisterende løsning. For de ambitiøse gik det hurtigt over stok og sten med stadigvæk mere avancerede løsninger. Alt det var muligt fordi vi havde et abstraktionsniveau ovenpå databasen, at ingen skulle rode med webservere, stå for at loade kodemoduler, etc.

Set med dagen øjne var vores 90'er løsning lidt bedaget og der var mange ting der kunne have været bedre. Men i det store hele formåede produktet at give ikke-IT kyndige mulighed for at designe avancerede flerbrugerløsninger.

Low code er en god ide til at hæve abstraktionsniveauet.

Problemet opstår når man skal ud af sin "low code" kasse. Når nogen vil hive kode moduler ind hvor abstraktionsniveauet er anderledes. Det kan ødelægge det hele. Man er nødt til at finde en fornuftig model for at integrere med resten af verden uden at det ødelægger den abstraktion der findes "inde i kassen". Jeg rodede dengang med en messaging baseret approach som jeg stadigvæk tror rigtig men aldrig blev særlig god dengang.

Læg så oveni behov så som release management, version control, review, branch-merge af code, multi-team development, etc. Der falder mange low code miljøer nemt sammen. Fx. er der lavet mange løsninger i stored procedures i SQL databaser hvor ovenstående altid er sat på med tyggegummi.

Det med udviklingstiden er relativt men i en perfekt verden så er det sikkert rigtigt! men ingen tvivl om at det bliver det nye buzzword og om kort tid kan/er alle udviklings-værktøjer low code.... og efter det kommer Lean code fordi det kan mere end Low code :=)

ThoughtWorks har begåen en IMHO lidt mere balanceret intro til hvad man kan og ikke kan forvente af low-code løsninger: https://www.thoughtworks.com/insights/articles/making_case_low-code_platforms De har også været omkring emnet i deres technology podcast: https://www.thoughtworks.com/podcasts/democratizing-programming (en udmærket podcastserie i øvrigt).

Balladen bliver jo gerne at de første 70% af en ikke-triviel løsning kan laves "uden kode", de næste 25% kan ordnes med at skirve lidt kode rundt i hjørnerne (typisk tricky inputvalidering og integtrationer), og de sidste 5% kan bare ikke lade sig gøre overhovedet.

(Men husk lige at tjekke afsenderen! Forrester lever af at promovere vendors med softwareprodukter/-services at sælge, så klart vil de have folk til at prøve low code (igen). ThoughtWorks leverer udviklings- og arkitekturbistand, så klart de vil snakke om de problemstillinger, hvor low-code ikke hjælper dig)

Hvad er low code ?

Er sådan noget som eksempelvis Shiny pakken til R low code ?

https://shiny.rstudio.com/

Denne artikel er en gentagelse af lignende udsagn som jeg har løbet ind i de sidste 40 år.

Den tidligere nævnte undersøgelse viste, at low code skar udviklingstiden ned til det halve.

I forhold til hvad? Hvis sammenligningen er udvikling i Java/C#, så skal der ikke så meget til.

Og så kunne bankerne selvfølgelig tilrette løsningen,« udtaler analytikeren til SD Times.

Halv udviklingstid, betyder sikkert elendig skaleringsevne.