Grad av kaos i utvikling

Stikkord: entropi, prosjektledelse, formidling, kaos.

Konteksten vår er alltid til en viss grad kaotisk eller ryddig. Hva skjer da med tingene rundt oss? Går de mot orden eller mot kaos? Ofte avhengig av person og situasjon. Noen er ryddige, andre er rotete. Noen ganger skal vi legge fundamentet for et langvarig programvareprosjekt, og andre ganger skal vi skrive en snutt for å løse en enkeltoppgave.

Vi velger oss alltid en grad av kaos å arbeide i. Journalisten med all informasjonen han jobber med spredd over hele pulten. Professoren med stabel på stabel av åpne bøker. Prosjektlederen med det strøkne skrivebordet, og alt satt i rett perm. Jeg mener ikke det finnes en ideell grad av kaos – selv om vi skulle ønske oss det. Er det ikke lett å ønske at vi hadde “litt mer struktur” på det vi driver med? Struktur kommer med en kostnad. Det er vanskeligere å tenke på ting som ikke passer inn i strukturen. Når andre skal kunne forstå hva vi jobber med er imidlertid struktur alfa omega. Struktur kapper informasjonen i nyttig og unyttig, og det er lettere lære å noe når nyttig er klart og tydelig adskilt fra unyttig. Hva om streken er tegnet litt feil; om vi ved et uhell har plassert nyttige og unyttige ting i feil bunke? Spiller liten rolle; rekkefølgen av ting lært blir kun litt forskjellig.

Grad av kaos er et nyttig utgangspunkt for vurdering av programmeringsspråk. Noen programmeringsspråk påtvinger innsats for å holde orden. Disse er ofte statisk typede:

• Haskell krever at vi holde typene våre i orden. Grensesnitt må defineres og være klare, slik at de kan typesjekke. Typene kan igjen brukes av den som skal lære å bruke grensesnittet: vedkommende får tydelig tilbakemeldinger på hva som er lov og hva som ikke er lov.
• Java krever at vi organiserer koden vår i klasser. Klassifisering for orden! Dette fungerer meget bra når klassifisering er hva vi trenger. For andre abstraksjoner kan det bli vanskelig. Klasser er i tillegg en mer rigid abstraksjon enn typer. Vi må da enda tidligere vite hva vi egentlig lager, ellers må vi gjøre store endringer seinere.
• COBOL var et tidlig forsøk på å få forståelig kode, og oppmuntre til skriving av dokumentasjon.

Andre språk gir frihet. Disse er det gjerne raskere å komme igang med, men gir en større kneik å klatre når ting begynner å bli stort. “Hva mente jeg egentlig her?” er noe man tvinges til å besvare tidlig i språk med høye krav til konsistens og struktur. Å se inkonsistenser tidlig kan gi muligheten til å endre designet tidlig, og således fikse tidlig uten å grave sin egen grav. På den andre siden er det stor verdi i frihet når man utvikler en idé. Jo raskere man kan gå, jo flere runder feedback kan man få kjørt. Å slippe “avbrekk” er en god ting.

• Python er fantastisk lett å komme i gang med. Alle filene du skriver kan kjøres direkte, og feedbacken fra kjøring kan bli kvikk. Verktøy som live-py-plugin hjelper i tillegg godt til.
• Clojure har jeg kommet i gang med i det siste, og erfaringen med feedback er meget god. Så god at den kan bli ytret som et problem, for når utviklingen raser unna, kan det bli opprydningsarbeid …

Hvilken grad av kaos skal du legge deg på i ditt neste prosjekt?