Når idé og virkelighed clasher: Tidsestimater, kode, skarphed og motivation i spænding

Der er en særlig spænding, som opstår, når idéer, tidsestimater, programmering, sikkerhed, arkitektur og faglig stolthed ikke følges ad. En spænding, jeg har oplevet mange gange – og som jeg stadig lærer af.

Et velkendt scenarie

For cirka 20 år siden arbejdede jeg for en ejendomsmægler – en branche, jeg har været dybt involveret i gennem årene. Han havde fået en god idé til en funktion på sin hjemmeside. Jeg var alene ansvarlig for alt det tekniske, og vi havde et tæt og tillidsfuldt samarbejde.

Problemet opstod, da projektets kompleksitet blev undervurderet. Tidsestimatet – sat i god tro og med entusiasme – viste sig at være alt for optimistisk. Funktionaliteten blev annonceret og markedsført, længe før jeg var i nærheden af at kunne levere noget færdigt.

Det var ikke et spørgsmål om dovenskab, men om manglende erfaring – og måske naivitet – fra både min og hans side. Og det er netop her, kernen i dilemmaet opstår: For mange udviklere befinder sig i krydsfeltet mellem vision og virkelighed.

Når kode ikke kan presses frem på kommando

Som udvikler oplever man ofte, at opgaver virker overskuelige i starten. Det ser simpelt ud på overfladen. Men jo dybere man graver, jo flere afhængigheder, begrænsninger og tekniske udfordringer dukker op.

Og kodning er sjældent noget, man bare “tvinger frem”. Det kræver overblik, forståelse og – ikke mindst – tid. Nogle gange kommer løsningen hurtigt. Andre gange skal man sove på det. Det er en del af det kreative, tekniske arbejde, som ikke altid kan tidsfastsættes præcist.

Den usynlige del af udviklingsarbejdet

Meget af mit arbejde foregår bag kulissen. Tvivl, research, læring, vurdering af alternativer. Når man arbejder med mennesker uden teknisk baggrund – og det gør jeg ofte – er det ikke altid nemt at forklare, hvorfor noget tager længere tid end forventet.

Og jeg forstår det godt: Idéen er klar, og løsningen ser ligetil ud. Men virkeligheden er, at det kræver mere end bare at skrive lidt kode. Det kræver struktur, sikkerhed, dokumentation, test og ofte rettelser, man ikke kan forudsige ved første gennemgang.

Tidsestimater og faglig stolthed

I dag er jeg blevet langt bedre til at vurdere opgaver realistisk – og til at sætte grænser. Men jeg har også bevaret den faglige stolthed, der får mig til at ville levere noget, jeg selv kan stå inde for. Det er ikke altid den hurtigste vej. Men det er den rigtige for mig.

Jeg har også lært, at det er vigtigt at tale om det, der ikke er synligt: teknisk gæld, fremtidig vedligeholdelse, risiko for forældelse. Mange af de kompromiser, der træffes for at få noget hurtigt i luften, koster dyrt senere.

Når løn ikke kun handler om tid

Som selvstændig har jeg måttet forholde mig til et andet aspekt: aflønning. Når man ikke længere bare får løn for sin tilstedeværelse, men for det konkrete produkt, bliver forretningslogikken endnu tydeligere.

Hvad er en “interessetime”, og hvad er egentlig “produktionstid”? Hvem betaler for den ekstra time, jeg bruger på at gøre det smartere? Og hvor går grænsen mellem leverance og faglig udvikling?

Det er ikke altid nemt at adskille. Men jeg forsøger.

Jeg er stadig i gang med at lære

Jeg har ikke knækket koden fuldstændigt endnu. Men jeg har lært at stille flere spørgsmål, før jeg siger ja. Jeg har lært, at et godt samarbejde bygger på klar forventningsafstemning. Og jeg har lært, at det er okay at sige: “Det her tager længere tid, end du tror.”

For mit mål er ikke bare at levere noget, der virker nu – men noget, der også holder i morgen.
Det er i balancen mellem idé og eksekvering, at de bedste løsninger opstår – og det kræver tid, tillid og ærlig dialog.