Löftena om low code-utveckling kunde inte vara mer förföriska. Vem vill inte göra mindre arbete? Vem vill inte luta sig tillbaka och låta de förbannade maskinerna sköta jobbet? Vi har ju trots allt sagt åt dem vad de ska göra i årtionden. De borde ha lärt sig en sak eller tre vid det här laget.
Den goda nyheten är att fler och fler företag har hittat sätt att skapa paket som är värdiga den mycket omtalade frasen low code. Vissa är så bra att de kanske redan är redo för den ännu mer hajpade frasen no code.
Faktum är att programvarustackarna har förändrats genom en blandning av sofistikerade dialogrutor, avsevärt förbättrade dra-och-släpp-gränssnitt, mer motståndskraftiga databaser och bättre integrerade utvecklingsmiljöer. Att lägga till lite av det som kan kallas artificiell intelligens gör inte saken sämre.
Vi har alla sett säljdemonstrationerna. Efter några klick är stacken igång. Med ytterligare några klick integreras den med det lokala LDAP-systemet, så att alla på kontoret kan logga in och utföra sitt arbete. Några klick till och systemet börjar pumpa ut rapporter och kalkylblad. För de människor som har turen att fortfarande vara en del av arbetsflödet ser det hela ut som magi.
Men även när de fina demonstrationerna är gjorda och koden fungerar som den ska finns det anledning att tänka till en extra gång. Bakom den välpolerade fasaden finns problem som inte kan åtgärdas genom att klicka på en enkel dialogruta.
Trots alla löften och till och med obestridliga framgångssagor från företag som levererar lösningar med low code finns det tyvärr skäl att vara mer än lite försiktig. Vissa saker är inte så bra som de verkar. Här är sex skäl till att vara försiktig med att svälja alla löften.
Automatisering gör oss korkade
Low code-försäljningsargumentet är att datorer och automatisering gör människor smartare genom att erbjuda en datoriserad hävstång som multiplicerar vår intelligens. Kanske det. Men du kanske också märker att när människor börjar lita på maskiner slutar vi ibland att tänka själva. Om algoritmen säger att det är rätt sak att göra så gör vi bara som den säger.
Det finns oändligt många exempel på den katastrof som kan bli följden av sådan tanklöshet. År 2016 blev flygplatser överfulla och många flyg försenade på grund av ett datorfel som gjorde personalen förvirrad. Personalen ”visste inte vem som redan hade gått igenom gaten”, enligt en tidning. Förr i tiden kunde vi människor fortfarande ta över och till exempel landa planet i East River i händelse av ett systemfel. När vi börjar förlita oss för mycket på maskiner, särskilt med tanke på frestelserna med low-code, kommer vi då fortfarande att kunna mobilisera oss i en nödsituation?
Majoriteten styr
Low code-lösningar är utformade för att tillfredsställa majoriteten. Om ditt företag är lite annorlunda är det inte säkert att anpassningsmöjligheterna räcker till. I slutändan kommer du också att börja följa mängden, och ditt företag kommer att bli mer likt resten. Det kanske inte spelar någon roll, men om ditt företag är beroende av att ha sitt eget speciella arbetsflöde, process eller tillvägagångssätt är det enda sättet att stödja det att skriva din egen kod.
Skräp ackumuleras
När människor skriver kod gör vi naturligtvis det minsta möjliga arbete som krävs, vilket är förvånansvärt effektivt. Vi tar inga genvägar, vi implementerar bara inte onödiga funktioner. Low code-lösningar har inte den fördelen. De är utformade för att passa alla, vilket i datorkod innebär bibliotek fyllda med ändlösa if-then-else-satser som testar alla eventualiteter i nätverket.
Low code är av naturliga skäl mindre effektiv eftersom den alltid testar och omtestar sig själv. Förmågan att anpassa sig automatiskt är trots allt den magi som säljteamet säljer. Men det kommer också att vara så mycket mindre effektivt än handtrimmad kod som skrivits av någon som kan verksamheten. Kanske är detta extra krångel inte så farligt till en början. Molnföretaget kanske ger dig massor av gratis krediter. Men så småningom, när ditt projekt växer, kommer någon att behöva betala för alla dessa extra if-then-else-loopar.
Bias i maskinen
Trots AI:s alla fantastiska förmågor är det ingen som riktigt vet hur mycket partiskhet och felaktigheter som döljer sig i dess modeller. Low code-plattformar har samma problem.
Det här är inte ett nytt problem. De människor som ersätts av low code-plattformar har alltid haft massor av fördomar som påverkat den programvara de skapat. Det är bara det att vi har kämpat med mänskliga fördomar i årtusenden nu, och vi har utvecklat många system för att bekämpa dem framgångsrikt. Vi är inte perfekta, men vi förstår en del av våra brister.
Low code-system är nya. Vi har precis börjat förstå hur de kan göra subtila och inte så subtila misstag. När vi väl har kommit över vår känsla av vördnad och slutat att automatiskt lita på de magiska algoritmerna, kanske vi börjar hitta ett sätt att bekämpa de fördomar som finns dolda på insidan.
Tveksamma förbättringar
Hur mycket av arbetet med programvaruutveckling handlar egentligen om att brottas med semikolon och variabeltyper? Hur mycket mer av arbetet går åt till möten med intressenter som ber dig att flytta knappen några pixlar åt vänster och lägga till lite mer rött i bakgrundsfärgen?
Viss kodning är mentalt utmanande, men en stor del av den är ytlig. Det verkliga arbetet är att hantera människor. Ofta ersätter lågkodversionen av ett program ett anrop av en biblioteksprocedur med en dialogruta där du anger de tre RGB-nyanserna för den bakgrundsfärg du vill ha. Är det så mycket enklare att skriva in dessa parametrar i en ruta än att skriva en rad i Java, Python eller C++?
Vi vill gärna föreställa oss att dialogrutor med low code sparar tid åt oss, men i många fall är de bara en fasad på samma mentala arbetsflöde som designtänkande. Det snygga low code-gränssnittet kan vara mer effektivt än att läsa igenom dokumentation och leta efter rätt syntax för ett proceduranrop. Men det är ofta inte en så stor tidsbesparing som man kanske förväntar sig.
Dolda kostnader
När low code fungerar bra är alla nöjda med att bara klicka. Men när det inte fungerar som det ska är det bara en riktig programmerare som kan lista ut vad som är fel. Ibland är problemet att du behöver göra något som inte är standard och som low code-systemet inte är utformat för att hantera. Ibland har du pressat systemet så långt att det börjar krångla eller krascha. I vilket fall som helst är det bara en riktig programmerare som vet hur man skriver riktig kod som kan hitta en lösning.
Problemet med low code är att det ofta bara löser enkla problem som syntax. Allt under ytan kräver fortfarande en duktig kodare som kan resonera kring alla dolda mekanismer som vi inte längre kan se. Low code-system är fortfarande programvara, och det går inte att komma ifrån behovet av någon som talar deras språk – det vill säga språket för bytes, arrayer och datastrukturer.
Historien upprepar sig
Inget av detta är nytt. År 1841, när vi såg hur tekniken förändrade transporter, textilier, krigföring och nästan alla delar av samhället, tog Ralph Waldo Emerson en paus och skrev en essä med titeln Self-Reliance.
”Samhället går aldrig framåt”, förklarade han:
”Det går tillbaka lika snabbt på ena sidan som det går framåt på den andra. Det genomgår ständiga förändringar; det är barbariskt, det är civiliserat, det är kristnat, det är rikt, det är vetenskapligt; men denna förändring är inte förbättring. För varje sak som ges, tas något. Samhället tillägnar sig ny konst och förlorar gamla instinkter.”
Detsamma gäller för low code. Därmed inte sagt att vi ska kasta bort den eller överge den vägen. Vi gav aldrig upp tanken på att använda teknik för transport eller tillverkning, vi insåg bara att de tillgängliga lösningarna inte var perfekta. Tekniken medför dolda faror, och många av dem kan bara lösas genom noggrann uppmärksamhet och stora mängder mänsklig intelligens.