Udviklere skal ikke frygte no-code: Fjerner snarere de kedelige opgaver

20 kommentarer.  Hop til debatten
Udviklere skal ikke frygte no-code: Fjerner snarere de kedelige opgaver
Illustration: Eirik Tangeraas Lygre.
Det fantastiske ved no-code er fleksibilitet i frontend-udvikling, lyder det fra norsk virksomhed.
26. august 2021 kl. 02:46
errorÆldre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

»Kreativ ødelæggelse« – skrev den østrigske økonom Joseph Schumpeter – er den proces, hvor innovation »uophørligt revolutionerer den økonomiske struktur indefra.«

For sociologen Max Weber var effekten af ​​en sådan ubønhørlig teknologisk udvikling tvetydig: den skaber rigtig nok nye jobs og muligheder, men den producerer også overflødighed og usikkerhed. For hele tiden er vores erhvervede fagkundskaber også med til at forme vores identitet, det er ikke kun erhverv, der udkonkurreres af nye teknologier, men også os fagfolk, ifølge Weber.

Log ind og få adgang
Du kan læse indholdet ved at logge ind eller oprette dig som ny bruger.
20 kommentarer.  Hop til debatten
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
20
27. august 2021 kl. 12:49

VEV, som artiklen tager udgangspunkt i, er et mini CMS:

https://www.vev.design/pricing/

Med deres såkaldte "no-code" løser de en mikrosopisk andel af et udsnit af en lille delmængde af opgaver relateret til websites. Det er i den optik at lederens udtalelser om trends skal afvejes.

Adspurgt drejer deres produkt sig om visitkorts-websites:

we recommend keeping to under 20 pages in one project

Og ja, der er selvfølgelig en code-editor til deres "no-code" system:

https://www.vev.design/platform/code-editor/

Held og lykke med no-code, når der skal laves andet end et slideshow.

Mig bekendt er alle systemer således "no-code", når først koden er skrevet og den leverer et klik-konfigurerbart interface.

19
27. august 2021 kl. 11:28

Fremtiden i industrien er helt sikkert at programmøren skal lave mindre kode, men det gør ikke noget da det bliver det simple og gentagelserne der forsvinder - vi kommer til at sidde og lave alt det sjove i stedet.

Ikke for at nedgøre, det er muligt at operatøren skal lave mindre kode, men al den kode der f.eks. eksisterer i Universal Robots er altså ikke opstået ved ren magi, så der vil helt sikkert blive ligeså meget (eller mere) brug for programmører i fremtiden.

Fuldstændig som at de fleste kan betjene en vaskemaskine, og ikke selv skal programmere den til at lave en finvask (med alle de iterationer der nu er i det), men bare kan vælge det, fordi "nogen" har programmeret maskinens styring.

18
27. august 2021 kl. 11:03

"bullshit andespil"

Det er det nye sort!

17
27. august 2021 kl. 10:22

Prøv at kig i noget mere avanceret PLC kode- det er rigtigt at det er startet som noget meget simpel logikstyring. Men de fleste PLCer i dag indeholder meget mere end det, vil tro at 30% af alle maskiner i dag programmeres i Structured Text (ST) som er del af IEC-61131-3 standarden.

Jeg er selv PLC programmør og jeg holder selvfølgelig alt hvad jeg kan i simpelt kode da det er nemmere for andre at fejlfinde på, men tror da 25% af koden jeg laver er i ST, det er ekstremt effektivt til håndtering af større mængder data.

Men der er da mange ting der er nemmere i en PLC, alt det der med hukommelse f.eks. jeg har specifikke adresser at arbejde med eller bare tags - jeg bestemmer selv og der er kun to ting i det der kan give problemer - enten at overskrive noget man bruger eller at man løber tør!

Vi ser i industrien samme tendenser - var for et par uger siden ude og se på en ny robot, den har 3 måder at programmere den på: Flytte den med hånden for at lave helt simple programmer (det kan andre også) Simpelt drag and drop programmeringssoftware til dem der ville lave det lidt mere avanceret. Den store stoftware pakke med simulering mm. her kan også laves avancerede funktionsblokke som kan importeres i den simplere software

Fremtiden i industrien er helt sikkert at programmøren skal lave mindre kode, men det gør ikke noget da det bliver det simple og gentagelserne der forsvinder - vi kommer til at sidde og lave alt det sjove i stedet.

16
26. august 2021 kl. 23:00

hvis

Jeg formoder det er et subtilt hib til dette fantastiske debatforum, som giver en et meget kort vindue til at nå at rette fejl i.

Måske V2 skulle lave en "app(s)", så løser alt sig jo på magisk vis - og det er jo slet ikke nødvendigt at kode mere!

12
26. august 2021 kl. 13:18

HMI

Det erjo sådan set bare brugerinterfacet, det siger intet om programmering som så.

PLC

Hvordan skal man programmere en Programmable Logic Controller uden programmering (af en eller anden slags)?

SCADA

SCADA er så meget mere (og i øvrigt en hvepserede at stikker hænderne ned i) at man slet ikke kan tale isoleret om programmering eller ej.

Tilgengæld kunne man måske argumentere for, at vi trænger til større udbredelse af CMS-systemer der også henvender sig, til den døende desktop og de knap så døende mobile platforme.

Øhh, og hvad mener du lige med det?

Generelt er der en tendens til at bare man kaster et nyt bullshit-buzzword(!) på banen, f.eks. no-code, så forsvinder mellemliggende kode (og tænkearbejde) på magisk vis - ligesom det helt store modeord er "apps", som ligeledes på magisk vis kan løse alle livets problemer.

10
26. august 2021 kl. 12:27

bullshitbanko

Jeg har før hørt udtrykket buzzwordbingo. Det var vel det, du mente?

9
26. august 2021 kl. 11:48

Nu er det jo ikke ligefrem en mindboggin nyskabelse. Vi har pt. miljøer som HMI, PLC, SCADA, som der alle handler om at binde komponenter sammen, uden brug af kode. (Med større og mindre held.) Det helt store lige for tiden, er IOT Dashboards (som der må høre under HMI), som der jo specifikt går ud på at bygge brugerinterface, uden at ty til kode. Indenfor Web, er der mere eller mindre ikke nogen der bygger sider mere, uden at de starter ud med et CMS. I programmer som LabView, bygger man komplette programmer, uden nogensinde at nedlade sig til kode. (Til gengæld får man musearm.) Derudover gør alle moderne GUI framworks, deres ypperste, for at adskille GUI og kode.

Tilgengæld kunne man måske argumentere for, at vi trænger til større udbredelse af CMS-systemer der også henvender sig, til den døende desktop og de knap så døende mobile platforme. Men igen, vi kommer hurtigt ud i noget der allerede er afprøvet i et utal af udgaver. Microsoft Access Forms anyone?

8
26. august 2021 kl. 11:12

Jeg kender jo ikke til lowcode i detaljer, men som andre har bemærket vil det alt andet lige gøre det sværere at lokalisere ændringer hvilket vil medføre unødvendigt omfattende regressionstest, som igen vil få behovet for test eksperter og QA'er til at eksplodere.

Det bliver efterhånden svært at finde en programmør i mellem horder af Testere, Supportere, Infrastruktur folk, Sikkerhedseksperter, Projektledere, Arkitekter, UX eksperter, Scrum mastere, ledere og andet godtfolk.

Så der bliver nok ikke færre programmører, men de bliver sværere at finde.

6
26. august 2021 kl. 11:00

Da jeg blev uddannet som EDB-assistent for mere end 40 år siden fik vi at vide, at det med kodning nok snart var forbi.

Vi venter stadig :-)

5
26. august 2021 kl. 10:56

Meget enig.

Og så er der også lige en anden lille detalje som ikke er uvæsentlig - hvor er S'et for sikkerhed i no-code?

Træerne gror ikke ind i himlen, og selv om der kommer nye sprog på banen i en lind strøm, så løser det basalt set samme opgave - og domænekendskab er altså vigtigere end at spille bullshitbanko.

4
26. august 2021 kl. 10:37

Jeg er enig, syntes også min erfaring er omvendt. Det er oftest udviklerne som spørger om de ikke kan bruge noget som er lavet i forvejen istedet for at starte fra bunden når der kommer opgaver.

3
26. august 2021 kl. 09:48

Hvor er denne kæmpe gruppe af udviklere, som frygter for deres job og derfor som gammeldags maskinstormere kæmper imod low-code?

Eksisterer de overhovedet andre steder, end som stråmænd i den fortælling low-code-fortalerne gerne vil give topledelsen?

Kan det være, at de udviklere som kæmper imod low-code IKKE gør det fordi de frygter for deres job, men fordi de måske kender deres historie og derfor erindrer hvordan CASE-værktøjer (Computer-Aided Software Engineering) som COOL:Gen lige om lidt ville gøre alle udviklere arbejdsløse - men reelt ikke gjorde andet, end at generere flere penge til dem der havde opfundet det og mere arbejde til udviklerne, som skulle få "low-coden" til faktisk at fungere efter at en ikke-udvikler havde siddet og trukket rundt med musen i nogle måneder?

Ikke alt der glimter er guld. At man kan huske sidst low-code-agtig teknologi skulle revolutionere softwareudvikling - og hvordan det ikke kom til at ske - betyder ikke, at man er hverken reaktionær eller maskinstormer. Det betyder blot, at man ved hvorfor det ikke kommer til at fungere på mellemlangt sigt - og følgeligt forholder sig kritisk til det low-code folkene lover.

2
26. august 2021 kl. 09:30

Eller at den simple WYSIWYG-editor overskriver links som er lavet i HTML-editoren (jeg kigger på Microsoft Power Apps Portals her).

Nocode eller lowcode er grundlæggende et mere omfattende framework end f.eks. .Net, Angular, Vue, React. Introduktionen af online forums og www-bulletin boards (f.eks. phpBB) og CMS var første skridt på vej mod lowcode, og i dag bygger næsten ingen et CMS fra bunden selv. Det ville da også være kedeligt arbejde. Det rejser også spørgsmålet: Hvor ligger forskellen mellem lowcode og ikke-tilpasset standardsoftware?

Hvis vi alligevel kigger ind i en fremtid hvor Danmark kommer til at mangle i tusindvis af it-folk, så er det måske smart nok, hvis der er lidt genveje for dem, som vælger branchen.

1
26. august 2021 kl. 07:26

Problemet jeg ofte har set med disse værktøjer er at man enten slet ikke kan lægge outputtet fra sådanne værktøjer i git, for det lever inden i en SaaS, eller at det ender med en kæmpe XML eller JSON fil, hvor det at ændre et komma i GUIen medfører kæmpe diffs, hvor man ikke kan reviewe ændringen.

Der er vel ikke noget til hinder for at sådanne værktøjer gemte i et eller andet højniveau DSL, så diffs er meningsfulde og "ligner" kodeændringen.

For mig er dette afgørende når jeg skal skelne mellem et brugbart værktøj og legetøj.

Det er faktisk også et problem for mange andre filformater, Office og Adobe f.eks.