Om å anerkjenne no-code

Dette er et lite innspill i diskusjonen rundt no-code løsninger, som bidratt til av Pål-Andre Kjøniksen.

"No-code" er da en samlebetegnelse på verktøy som lar en utvikle løsninger uten å faktisk skrive kode. Dette kan både være frie løsninger som lar deg lage "hva du vil", eller det kan være løsninger som lar deg utvide og tilpasse funksjonalitet innad i et eksisterende produkt. Jeg anerkjenner både ønsket om no-code generelt, samt dens nåværende og fremtidige eksistens.

Jeg for min del er ikke redd for min egen evne til å kunne produsere løsninger i no-code-miljøer ved behov. Ei mener jeg heller ikke at det ikke finnes noe marked for de: de løser helt klart et problem - på samme måte som alle andre nye rammeverk, språk, teknologier osv jo gjerne sikter på å løse sine gitte problemer. Men, akkurat som disse, så markedsfører jo heller ikke no-code løsningene seg med problemene og begrensningene de tar med seg.

Så for å oppsummere de umiddelbare gevinstene på et forretningsnivå slik jeg ser det:

• Å raskere kunne levere/demonstrere en gitt løsning
• Å legge til rette for enklere å justere enkelte aspekter av løsningen etter dens initielle utvikling

Nå er jo “no-code” omtrent like kodeløst som “serverless” er serverløst. Det man faktisk sitter igjen med er systemer som gjerne genererer flere instrukser enn potensielt sett den koderike koden.

Det er i hovedsak to potensielle konsekvenser ved denne retningen som bekymrer meg:

• Det at vi generelt sett reduserer forståelsen for de underliggende mekanismene av et system, noe som forøvrig har vært symptomatisk i lang tid allerede all den tid vi skal abstrahere oss lenger og lenger vekk fra det konkrete
• Vi overforbruker maskinvare og energi - da tatt opp på et makroperspektiv

I tillegg har man også de potensielle problemstillingene:

• Når man tar frem en no-code løsning så gjøres dette innad på en gitt plattform og man får da i mange tilfelle en lock-in effekt man må ta høyde for om man på noe tidspunkt skal skifte denne
• Om miljøet du er i ikke tilbyr den funksjonaliteten du trenger så må du fortsatt ty til kode. Denne må da tas frem på en slik måte at den lar seg integrere på en gode måte.

I mikroperspektiv virker dette kanskje ikke problematisk, men tatt opp i et makroperspekt så finner jeg dette mer bekymringsverdig. Jeg mener ikke at alle skal kode alt i assembly-varianter og C, men man må være bevisst på hva valgene man gjør innebærer. Ikke minst ønsker jeg at folk har et noe lengre og mer holistisk perspektiv generelt når man vurderer konsekvensene av sine strategier. Som også Pål-Andre er inne på så bør no-code og ordinær kode kunne leve sammen i skjønn forening. Men: som jeg tror de fleste som har vært i programvareindustrien en stund har opplevd så ser man også alt for ofte at folk ikke tilnærmer seg ulike paradigmer og filosofier på en like reflektert måte og at man får mange "all-in" strategier.

Jeg ser ellers veldig godt verdien av no-code i prototypestadier samt i ulike former for lavfrekvente, API-drevne løsninger, der man f.eks. allerede er nettverksbundne.

Nå vet jeg at det finnes folk der ute som innehar større ekspertise på spesifikt no-code-løsninger, så vær så snill å plukk argumentene og bekymringene mine fra hverandre. Jeg er spesielt interessert i å se eksempler på generering av god, effektiv kode.

Mye rundt de generelle bekymringene mine har jeg også tatt opp i tidligere innlegg - men uten å nevne no-code som spesifikk abstraksjon/verktøy.