Var på skiferie i denne uge. Det viser sig, at når man er skiløber på de blå pister og bliver skubbet videre til de røde pister, får man cirka 1.000 gange mindre tid til at tænke på AI. Prioriteten bliver tanker som “Hvordan skal jeg klare det næste sving?” og “Gud, lad den snowboarder løbe længere væk fra mig.” Måske skulle jeg prioritere ekstrem bevægelse i min dag for at afbøde denne kvartlivskrise? Eller … måske er det bare endnu et lag af krisen.
Når jeg tager en pause fra mine mere dommedagsfokuserede AI-tanker, har jeg en tendens til at blive besat af at renovere vores typiske københavnske badeværelse på tre kvadratmeter. Det er nok min længste igangværende ChatGPT-tråd. Vi diskuterer hele tiden, hvor kompliceret det er at rive det ned selv og få professionelle til at bygge det op igen. På papiret lyder det ikke så kompliceret. Millioner af mennesker har gjort det før. Men hvad nu, hvis der er asbest? Du ved, hvor den samtale ender.
Jeg vil hellere have professionelle til at håndtere det og betale en højere pris for at sikre, at det bliver gjort ordentligt og lever op til mine forventninger og kvalitetsstandarder. Selv om jeg kan se alverdens YouTube-tutorials, er min tid bedre brugt på andre ting.
Denne tankeproces fører mig ofte tilbage til de ændringer, vi ser og fortsat vil se i ansættelsestendenserne for softwareingeniører. Efter det pandemiske ansættelsesboom i softwaresektoren og den efterfølgende korrektion er den langsigtede efterspørgsel efter udviklere fortsat stærk. Antallet af softwareingeniører forventes at vokse med ca. 17 % i løbet af det næste årti. Det, der ændrer sig, er ikke behovet for ingeniører, men hvordan virksomhederne anvender denne kapacitet. Organisationer bliver langt mere bevidste om, hvornår de skal ansætte internt, og hvornår de skal stole på ekstern ekspertise.
I min tidligere artikel, “Rethinking Software Development”, argumenterede jeg for, at det bliver billigere at kode og bygge software. Men ejerskab, udrulning og realisering af værdi er fortsat vanskeligt at etablere. I en tid med “vibe coding” og stadig mere tilgængelige værktøjer, der kan puste den opfattede ekspertise op, bliver det endnu vigtigere at være kritisk over for, hvornår man skal bygge, og hvornår man skal købe. AI fremskynder udviklingen, men det fremskynder også forfald af viden.
For at vende tilbage til badeværelsesrenoveringsanalogien er der masser af godt indhold på nettet, der forklarer, hvordan man udskifter rør i bruseren, omlægger rør og lægger fliser. Min partner og jeg kunne sikkert godt finde ud af det. Men er det noget, jeg kan stå inde for om mange år, når lejligheden har fået nye ejere, og jeg måske stadig hæfter for VVS-arbejdet?
Adgang til viden har aldrig været billigere. Det betyder ikke, at omkostningerne ved fejltagelser har ændret sig. Billig viden betyder ikke billige konsekvenser. Lad dette være den kraft, der styrer din beslutning, når du vælger, om du skal bygge eller købe softwareløsninger. Det kan føles tiltrækkende at bygge alting selv, når information og værktøjer er så let tilgængelige. Men urealiserede videnshuller er slow killers. At bygge løsninger, der er nemme at skabe, men svære at eje, vil i sidste ende aflede dit fokus fra det, der driver din værdi. Da jeg er bygherre i hjertet, kan jeg nemt brænde tid og penge af på at beslutte at bygge og eje noget, der er bedre at købe. Hvor er det søde sted mellem at bygge og købe? Ud fra min erfaring med at arbejde med ingeniører, der hurtigt kan absorbere viden på tværs af domæner og er meget dygtige bygherrer, kommer beslutningen om at bygge eller købe ofte ned på nogle få signaler.
Hvornår skal man bygge?
- Iterationshastighed er vigtig – Når du ser på et projekt med store tilpasningsbehov og en etableringstærskel for domæne-F&U, er det her, du vælger at bygge. Internt ejerskab bliver en fordel, da det giver dit team mulighed for at bevæge sig uden ekstern koordinering, eller endnu værre, tilladelse eller debat. Jo hurtigere du udvikler og lærer af systemet, jo mere værdifuldt bliver ejerskabet.
- Viden skabes internt – Som en sidebemærkning til det første punkt kan man sige, at hvis det at bygge en løsning øger din ekspertise, så gør det. Som Michael Scott ville sige, er det en win-win-win. Den viden, der opbygges gennem disse projekter, spredes internt. Det er en langsigtet investering for dig og dine medarbejdere. Outsourcing ville kompromittere muligheden for at udvikle ekspertise, som senere kunne vokse til din konkurrencefordel.
- Lav risiko for at fejle – Sidst, men absolut ikke mindst, skal du prøve at vurdere, hvad omkostningerne ved at tage fejl kan blive. Hvis fejlene er lette at rette op på og ikke får langsigtede konsekvenser, kan den læring, man får ud af at bygge, opveje omkostningerne ved at købe. I disse situationer bliver eksperimentet en vellykket investering snarere end en belastning.
Hvornår skal man købe?
- Skjult kompleksitet – Infrastruktur, sikkerhed, compliance og distribuerede systemer gemmer på lag af kompleksitet, som ikke afsløres, før der sker en fejl. Eksterne domænespecialister bidrager med erfaring, som hjælper med at undgå dyre forsøg og fejl.
- Ansvars- eller sikkerhedsrisiko – Omkostninger ved fejl er ikke altid tekniske; højere omkostninger ved fejl omfatter juridiske og økonomiske konsekvenser. Når sikkerhed, compliance og tryghed påvirkes, skal man træde varsomt. Fejl på disse områder skaber varige konsekvenser langt ud over implementeringen. Det er her, specialistprisen er din tryghed værd, og det er her, vi ser, at de fleste vibrationskodede løsninger fejler. Det er ikke nemt at genskabe den troværdighed, man har mistet på disse områder.
- Ikke-kernekompetence – Det hele handler om at forbedre dit værditilbud som virksomhed. Hvis den eftertragtede kapacitet ikke styrker dit værditilbud, kan det dræne ressourcer og aflede opmærksomheden fra det, der skaber din konkurrencefordel, hvis du bygger den internt. Ved at købe aspekter, der falder uden for dette område, kan dit team fokusere på områder, hvor ejerskab skaber værdi.
Når jeg tænker tilbage på dilemmaet med badeværelsesrenoveringen, var det egentlige spørgsmål aldrig, om vi kunne renovere det selv. Med nok tid, vejledninger og tålmodighed kunne vi sikkert godt. Og lad os være ærlige … en masse involvering fra vores fædre, haha. Det virkelige spørgsmål var, om vi havde lyst til at tage konsekvenserne af den beslutning mange år senere.
Softwarebeslutninger er ikke så forskellige. AI har sænket barrieren for at bygge næsten hvad som helst, men ansvaret for at eje det, man bygger, forbliver uændret. Systemer skal vedligeholdes, sikres, understøttes og være til at stole på, længe efter at den første begejstring over at bygge dem er forsvundet. Bare fordi man kan bygge noget, betyder det ikke, at man bør gøre det. I en tid, hvor det er nemmere end nogensinde at bygge, kan det blive en mere værdifuld færdighed at vide, hvornår man ikke skal bygge.
Indtil videre hæver lettere vidensindsamling tærsklen for, hvilken slags software vi vælger at investere i. Men de sande omkostninger ved at bygge utallige små interne løsninger er endnu ikke blevet fuldt ud afsløret. Vi vil sandsynligvis først forstå de omkostninger, når nogle af disse systemer begynder at fejle. I sidste ende handler mange af disse beslutninger om økonomi, og det er noget, jeg har tænkt meget over. Hvordan ændrer denne AI-revolution og den kommende agentiske æra prissætningen af softwareløsninger? Det vil jeg udforske i mit næste indlæg.
I mellemtiden skal man udforske byggemulighederne med et åbent sind og eksperimentere med AI-løsninger, der fremskynder leveringen, men være kritisk over for de langsigtede omkostninger.
Denne blog blev oprindeligt udgivet af forfatteren på Just Because You Can Build It Doesn’t Mean You Should.
