Noget af det mest lærerige i mit arbejdsliv har været at opleve kontrasten imellem, hvordan vi udviklede it-systemer i 0'erne og i 20'erne.

I 0'erne arbejdede jeg på et system, hvor jeg var med til at frigive hovedreleases hvert 1½ år.

Der er sket meget siden da både i teknologi og metode. I dag hos Schultz har vi teams, der deployer 10-20 gange om dagen, og andre teams, som deployer mindst hver 2. uge. Det er imellem en faktor 40 og en faktor 5.000 oftere end min erfaring fra 0'erne.

For der sker noget, når du releaser ofte - som er ud over den åbenlyse "time to market".

1. Vi lærer mere

Vi lærer mere. I hele min tid på den tidligere arbejdsplads var jeg med til én hovedrelease og to hotfixes.

Det er nærmest umuligt at blive dygtigere til noget, man aldrig øver.

Når vi releaser hver 2. uge og deployer endnu hyppigere, har vi konstante evalueringspunkter, hvor vi opnår "gratis" læring. Vi bliver med andre ord konstant dygtigere - hver eneste dag - i modsætning til en gang om året.

Vi lærte ikke bare mindre - vi blev nærmest dummere

Hvad værre er. Med personaleomsætningen i en it-virksomhed risikerer man hele tiden at sidde med nye medarbejdere, som skal release uden at have prøvet det før. Jeg nåede som sagt kun én hovedrelease i min tid.

Deployer man hver eneste dag, har alle i virksomheden prøvet at deploye mindst hundredvis af gange.

2. Vi eksperimenterer mere

Hvis man kun har ét skud i bøssen hvert halvandet år, så skal man helst ramme plet. Hver gang.

Det betyder, at risikovilligheden falder. Man eksperimenterer mindre. Man innoverer mindre.

Men der går også simpelthen for lang tid imellem eksperimenterne. Hvis man kun kan eksperimentere hvert halvandet år, går innovationen helt i stå. Man bliver ikke dygtigere eller mere produktiv, og man finder ikke smartere måder at gøre tingene på.

Når man deployer dagligt og releaser med få ugers mellemrum, kan man hele tiden slibe kniven og blive skarpere, mere effektive og finde på smartere løsninger.

3. Vi tør fejle

Hvis vi introducerer fejl i dag, retter vi dem ofte samme dag eller i løbet af få dage.

Hvis vi fejlede i 0'erne, kunne det tage ugevis og ofte månedsvis, før vi kunne rette fejlen. Det gav en 0-fejlskultur, som ikke var sund for hverken kunder eller medarbejdere. Vi måtte køre testrunde på testrunde for at være helt sikre på at have fundet fejlen, og alligevel blev vi mødt af det evindelige - "har I overhovedet testet det?".

Når vi fejlede, fejlede vi stort. For mængden af ændringer i en release var enorm. Når 30 mand har siddet i halvandet år og tilføjet, ændret og justeret et produkt, bliver mængden af potentielle fejl enorm. Hvis vi deployer flere gange om dagen, er det virkelig begrænset, hvor meget der kan fejle ved hver ændring. Og kommer der en fejl med ud, så ved vi præcis, hvor den er - for vi har næsten ikke ændret noget, og vi ved præcis, hvilken lille ændring der var tale om.

4. Vi siger mindre nej

Lange releasecyklusser har processer, som skal beskytte releasen - feature freeze-perioder, code freeze-perioder, test-runder.

I 0'erne byggede vi "kontrakter" og regler op omkring releasen for at beskytte den. Det betød, at vi måtte sige nej til ønsker, der brød de kontrakter, som skulle beskytte releasen. Vi sagde meget nej.

Vores nej kunne have store konsekvenser. For fik man ikke en ændring med i en release, kunne der gå yderligere halvandet år, før man fik sin ændring ud. Som mininum kunne der gå måneder indtil næste patch.

Vi siger måske stadig nej, selvom vi er langt mere risikovillige. Men når vi gør det, skal man ikke vente halvandet år. Så skal man vente et par uger.

5. Vi har det sjovere

De store releases gav en følelse af, at det vi lavede, var meget kompliceret og meget vanskeligt. Man følte sig nogle gange som en del af noget meget stort - også på en god måde. Men det var nok lidt fodslæbende.

For det var egentlig ikke så kompliceret. Vi gjorde det meget kompliceret. Vi har det sjovere her 20 år senere, hvor vores muligheder er helt anderledes. Det føles lettere at bygge software. Ikke lettere i betydningen "nemmere", men lettere i betydningen mindre tungt. Det er i hvert fald sjovere.

Jeg har den største respekt for de mennesker, jeg samarbejdede med dengang. Jeg lærte meget af dem, og vi lavede fede ting. Men tiden var en anden. De teknologiske muligheder gjorde det mere komplekst. Vores metodeforståelse var lavere. Og de konkrete omstændigheder, vores produkt var i, spillede selvfølgelig ind.

Vores industri er meget ung og meget umoden, men hvor er der sket meget på 20 år.