Relativt rå notater fra Open Space:

Første versjon skal være dårligere.

Konsulentselskaper ønsker å sette inn juniorkonsulenter.

Den guddommelige kunden eksisterer ikke, men er pulverisert.

Kostnadsrammen er eller bør være kjent i starten, selv om estimeringen gjøres enklere.

Forretningen opplever en stor klump som mindre risikabelt enn inkrementell produksjonsetting.

Viktig å finne kundegrupper som er gode kandidater for å prøve nye moduler. Kanskje nye kunder som ikke har noen forutinntatt oppfatning av produktet.

Om eksisterende legacy: Partisjonere systemet og lage trygge grensesnitt imellom. Dernest kan en av delene erstattes.

Bytt ut deler med noe som oppfører seg likt.

Introdusere tjenestelag.

Veldig godt definerte akseptansetester.

Parallellproduksjon.

Forberede brukerne på hva de ikke får.

Hva er det systemutviklere aldri gjør? Å fjerne funksjoner.

Analysere hva som blir brukt — studere eksisterende system for å finne ut hva som er viktig og hva som kan utelates i erstatteren.

Asgeir (frivillig referent)

Spørsmålet om Minimal Deployable Entity er naturligvis et spørsmål forutsetter at man velger å erstatte et eksisterende system med et nytt system etter store mengder utvikling. Min erfaring er at i alle fall noen organisasjoner kommer fram til konklusjoner rundt Minimal Deployable Entity etter mye smerte med utviklingen av et slikt nytt system (eller, etter det jeg har sett: systemtesten av det nye systemet!)

Hva da om vi sier at det er feil å erstatte systemet i sin helhet. Kan vi levere funksjonalitet og gradvis erstatte arkitekturen, samtidig som vi leverer ny verdi til det nye system.

Hvorfor skal noen leveranse behøve å være dårligere enn det vi har, når det vi har allerede er så dårlig? Hvorfor må vi erstatte systemet i en big bang?

Problemet er vel ikke alltid at det man har er så dårlig, funksjonalitetsmessig. Man vil gjerne legge til flere funksjoner til det man allerede har, men siden det man har er dårlig vedlikeholdsmessig (dvs kode som er forferdelig), så konkluderer man med at det er mye smartere å skrive hele greia på nytt.

Hvis man nå først skal skrive et system av ikke-triviell størrelse på nytt, så bør man i det minste gjøre det på den måten Johannes beskriver. Bytt ut en del om gangen. Ha hele tiden en kjørende versjon av systemet, slik at man kan reagere på nye krav til systemet umiddelbart.

Et kjapp presisering før jeg går ut i solen:

I et replacement prosjekt skal første versjon være dårligere, ikke fordi funksjonene i det nye er dårligere (de skal være like bra eller bedre). Derimot skal det nye systemet inneholde mye færre funksjoner enn det gamle. Kun de funksjoner som gir så stor verdi at de ikke kan unnværes skal være med.

I den ideelle verden bør MDE alltid være 4 uker. I min erfaring er det ikke alltid mulig. MDE er en kompromiss der man prøver å få noe i drift så fort som mulig uten at det skal gå ut over den daglige driften i for stor grad.

Her er et eksempel (fra virkeligheten) på et prosjekt der MDE blir større en 4 uker. En kunde ønsker å bytte ut et forretningskritisk system. Systemet er gammelt og lar seg ikke integrere med nye tjenester som vil gi kunden stor verdi. Problemet er bare at systemet i tillegg eksterndriftes av en leverandør som kunden har et anstrengt forhold til. Det er dermed utelukket å samarbeide med denne leverandøren for å gjøre tilpasninger i systemet.

En kunde ønsker å bytte ut et forretningskritisk system. […] Det er […] utelukket å samarbeide med [driftsleverandøren] for å gjøre tilpasninger i systemet.

Poenget er kanskje at vi skal jo ikke levere systemer, vi skal levere verdi.

Mitt eksempel er ikke fra virkeligheten, men fiktivt, for å forsøke å illustrere poenget: La oss si at systemet Niklas nevner er en nettbutikk. Og la oss si at den kritiske verdien er rundt tiden det tar å legge til nye produkter. Selv om vi ikke kan endre systemet: Kan det være mulig å redusere denne tiden på en annen måte? For eksempel ved å strømlinjeforme prosessen rundt? Eller kanskje screen scrape (ja, jeg vet: ick!) det eksisterende systemet der det er?

Eller la oss si at den kritiske tiden er tiden den tar for en potensiell kunde å finne produktet han ønsker å kjøpe. Kan vi lage en proxy foran det eksisterende systemet som kun håndterer søk?

Eller dersom det kun er redselen for den eksterne leverandøren som er driveren: Kanskje vi kan starte med å ta over kontroll over våre DNS records selv (DNS er den ene tingen jeg tror jeg som kunde aldri ville overlate til en leverandør!). Kunne dette være den største leverbare verdien neste uke?

Det er vel helt avhengig av hva som ligger i ordet “integrere” når det ikke “lar seg integrere”.

Når jeg skriver system så er dette bare en måte å referere til en samling funksjonalitet som gir kunden verdi. Som Johannes påpeker så er det mange ganger mulig å levere verdi på toppen av det eksisterende selv om man skal erstatte det. Dette er positivt av flere grunner, ikke minst at det gir en tid til å lære seg mer om den eksisterende løsningen. Samtidig har man på en måte bare forskyvt problemet frem i tiden. Førr eller siden kommer man til et punkt der man skal flytte den verdiskapning som håndteres av det gamle systemet til en ny løsning. Hvis det da viser seg at dette ikke lar seg løse på 4 uker så har man et problem. Hvis man kan gjøre det på 8 uker er problemet ikke så stort men hvis det tar 6 måneder begynner det å bli det.

Det jeg tror vi alle er enige om er at prosjekt som bruker 2-3 år for å lage noe før det settes i produksjon har et stort problem. Problemet blir bare noe redusert hvis de har interne releaser hver 4 uke som ikke settes i produksjon. Når vi snakker om store prosjekt så er det egentlig dette vi snakker om. Et prosjekt som er på 50 millioner men som kan levere verdi i produksjon hver 4 uke er mye enklere enn et prosjekt til 20 millioner som setter noe i produksjon først etter 18 måneder.

Jeg er veldig enig i at ting som ikke produksjonssettes før etter 2-3 år er et problem. Det jeg derimot ikke er enig i er at man må skille mellom “det gamle” og “det nye” systemet i en rewrite. Hvorfor kan man ikke heller videreutvikle den kodebasen man har?

I mange situasjoner så er jeg enig i at det beste er å videreutvikle det man har. IT folk har en tendens til å tro at bare man får byttet ut det gamle mot noe nytt så vil alle problemer forsvinne. Samtidig så finnes det situasjoner der det ikke er lurt å forsøke bygge videre på det man har. Eksempelet jeg nevnte er en sånn situasjon.

IT verden opplever med jevne mellomrom paradigmeskifte. På nittitalet var det Internett. På åttitalet var det overgangen fra batch til realtidsbaserte systemer. Jeg tror det ville være mye mer kostbart å videreutvikle et batch system til et realtids-system enn å skrive noe nytt.

Da tror jeg vi er ganske enige, Niklas! Tror heller ikke det stort sett lønner seg å refaktorere systemer til å overleve slike paradigmeskifter som du beskriver. Mulig man kan redde noe av koden.

Så hva gjør man når man kommer til en organisasjon som presenterer en enorm prosjektstruktur som skal levere noe etter en årrekke? (Jada, de sier de skal levere “første delleveranse” etter 6 måneder, men alle veit jo at det ikke skjer)

Det er jo da det blir spennende! Hvert prosjekt er unikt. En strategi for å redusere MDE som fungerer i et prosjekt kan være en katastrofe i et annet. Det som er vesentlig er å få organisasjonen å skjønne at man skal legge mye energi i å redusere MDE. I noen tilfeller må man gjøre investeringer som kan føles bortkastede på kort sikt men som vil betale seg på lenger sikt. Et eksempel på dette er å gjøre tilpasninger i et legacy system som senere skal avvikles.

Jeg ser meg om i verden nå etter prosjekter som har gått bra med en stor “minimal” deployable entity. Har noen erfaringer med vellykkede prosjekter som ikke var villige til å svelge den bitre pillen med å videreutvikle et stort system som “snart skal kastes” og i stedet erstattet det i en “big bang”? Med vellykket mener jeg her at det gitt sånn nogenlunde som man hadde forventet ved prosjektstart.

Hvorfor kan man ikke heller videreutvikle den kodebasen man har?

Det er ofte at kodebasen som eksisterer er så “unaligned” i forhold til forretningsverdien det skal yte. Dette gjelder (generelt sett) typisk for:
- dårlig arkitektur og mastodonter (overarkitektur)
- ekstremt høy teknisk gjeld
- meget kompliserte løsninger (WS-* :P)
- veldig gamle systemer (teknologien ikke lenger er lett å skaffe kompetanse til)

I slike prosjekter kan det være fornuftig å begynne med blanke ark og big rewrites. Ofte er videreutvikling mest kostnadseffektivt, men i tilfellene over tror jeg at det å refaktorere systemet og gjenbruke kode tvinger trangsynthet og gjør det vanskelig(ere) å forbedre løsningen. Uansett synes jeg at det er langt viktigere å bevare domenekunnskapen i prosjektet enn kodebasen – når man må forbedre noe drastisk. (Angående arkitekter har jeg litt ambivalent syn: Noen ganger kan det være lurt å bytte dem ut – med tanke på teknisk tilnærming til problemstillingen; Andre ganger kan det være lurt å beholde de samme – forutsatt de har utviklet sitt syn på ting).

Jeg har funnet et moteksempel, tror jeg: Et uvedlikeholdbart system med masse kjente feil som aldri klarte å komme hele veien til produksjon. Da er det vel bare å kaste, vel?

Hva gjør det uvedlikeholdbart? Hvorfor kom det seg aldri til prod? Har man ressurser igjen som var med å utvikle systemet? Sannsynligvis havner det under generaliseringen min for ekstremt høy teknisk gjeld – isåfall mener jeg: ja, pælm det ;)

Jeg tror at det ofte er nok å kaste deler av systemer. På et prosjekt jeg var på erstattet vi 30 000 linjer med 500 linjer ny kode (fra ca 75 (s)kloc til ca 45 kloc) (pluss en haug integrasjonstester) og utvidet faktisk funksjonaliteten, og fikk igang et system som hadde hatt “prodnekt” i 2 år (det ble utviklet 2004-2005, og først prodsatt 2008). Vi hadde ingen originale ressurser (en fare ved slik refactor!). Domenekompleksiteten var dog enkel å komme rundt – overarkitektur og tett kobling i kode var hovedproblemene, så vet ikke om systemet er representativt til ditt eksempel – aner meg at det var noen hundre-ganger enklere. Om dette er å forbedre kode eller slette er jeg ikke konkludent, men en kombinasjon fungerer veldig ofte. :)

Det at et system “aldri klarte å komme hele veien til produksjon” høres for meg ut som et klassisk eksempel på MDE som eser. Man når aldri helt frem til noe som aksepteres som godt nok til å sette i produksjon. Mer om mer resurser settes på å gjøre “små” rettelser i det gamle systemet. Den nye løsningen får mindre om mindre resurser…