OPERATIVSYSTEMER OG PROGRAMVARE

Hva om vi bygget alle systemer som lærende systemer?

En oppskrift på god programvareutvikling.

Espen Andersen, Tversoversk
Espen Andersen, Tversoversk Foto: BI
Espen Andersen, oktober 02021
17. okt. 2021 - 14:00

Denne kommentaren gir uttrykk for skribentens meninger.

En av mine favorittbøker er Stewart Brands How buildings learn: What happens to them after they are built, utgitt 01994 (og som en TV-serie på BBC i 01997). Stewart Brand er en tidlig teknologiguru og maker og sto blant annet bak The Whole Earth Catalog, som var en slags bibel for folk som ønsket å lage ting og klare seg selv på 70 og 80-tallet. (Han er også grunnlegger av The Long Now Foundation, hvilket er årsaken til at jeg skriver årstall med fem sifre her.)

How Buildings Learn er gitt ut i 01994.
How Buildings Learn er gitt ut i 01994.

En grunn til at jeg liker denne boken (og mener den bør omtales i Digi.no) er at boken er direkte relevant for dem som lager, bestiller og bruker informasjonssystemer. Hovedpoenget i boken er at en bygning alltid endres etter at den er bygget (og for så vidt mens den blir bygget også) – og hvis vi forstår denne utviklingen som en regel heller enn et unntak bør vi bygge hus som kan utvikle seg etter at de er ferdige og overlevert. Slike hus blir ikke gammeldagse, er elsket av de som bor eller arbeider i dem, og tenderer også til å være pene fordi evolusjon tenderer til å finne det som virker og som er pent.

Mange arkitekter liker ikke Stewart Brand og konseptet med bygninger som kan endres – ofte fordi en arkitekt har en visjon om hvordan en bygning skal være, og blir premiert for det. For en del arkitekter er det faktisk ganske skuffende at huset de laget ikke blir brukt på den måten de hadde tenkt. Som han sier i boken: «Alle bygninger er spådommer. Alle spådommer er feil.» Vi klarer rett og slett ikke å forutsi hvordan en bygning skal være, så derfor kan det lønne seg å gjøre den tilpasningsdyktig.

Bytt ut ordet «bygning» med «system», og, vel, du har en oppskrift på god programvareutvikling.

Seks lag

En illustrasjon av Stewart brands seks lag.
En illustrasjon av Stewart brands seks lag.

Hva ligger fast i en verden der vi skal verdsette fleksibilitet? Det første du må gjøre når du skal lage noe som er fleksibelt, er å bestemme deg for hva som ikke skal kunne endres. Stewart Brand deler bygninger inn i seks «lag» som alle endres i ulik takt:

  • Sted (site) er der bygningen står og hvordan den forholder seg til omgivelsene – den er «evigvarende» siden bygninger flyttes svært sjelden.
  • Struktur (structure) er fundamentet og bærebjelkene i bygningen, og har en levetid på 30-300 år).
  • Overflate (skin) er utsiden av bygningen og har en levetid på ca. 20 år for de fleste kommersielle bygninger, avhengig av teknologi og moteretninger.
  • Tjenester (services) er kabling, avløp, vann, ventilasjon, brannvern og andre ting en bygning trenger for å fungere. De trenger reparasjon og utskifting – kanskje hvert 7-15 år - og må derfor være tilgjengelige.
  • Rominndeling (space plan) er hvor vegger, tak, gulv og dører er i en bygning. Disse kan endres ofte – hvert 5-20 år, for eksempel.
  • Greier (stuff) er alt annet som er i bygningen – møbler, lamper, kjøkkenmaskiner, skjermer – og endres hele tiden, av og til flere ganger i uken. Ordet møbler kommer fra det italienske mobile, og man skjønner jo hvorfor.

Det er ikke så vanskelig å se hvilke deler av et informasjonssystem som må ligge fastere enn annet – APIer, for eksempel, er jo ikke noe annet enn hvordan systemene forholder seg til omverdenen, og de bør jo endres langsomt nettopp av hensyn til omgivelsene.

Gode komponenter

A Pattern Language ble utgitt i 01977.
A Pattern Language ble utgitt i 01977.

Den andre måten skape fasthet i en omskiftelig verden er å forholde seg til hva som er gode komponenter i et system – hva som alltid virker, nesten uansett i hvilken sammenheng den settes inn. Også her kan vi hente kunnskap fra arkitekturen, nærmere bestemt fra Christopher Alexanders bok A Pattern Language, utgitt 01977 (med medforfatterne S. Ishikawa og M. Silverstein). I denne boken identifiseres 253 mønstre (patterns) – enkeltteknikker som fungerer for brukere av byer og bygninger. Det er mange eksempler, gjerne utformet som utsagn av typen:

  • Bygninger bør bygges på de verste stedene av tomten, ikke de beste
  • Balkonger som er under seks fot brede blir sjelden brukt
  • Folk vil alltid foretrekke et rom som har lys fra to sider
  • Hvis folk må vente, skap et område som gjør ventingen til noe positivt
  • Før du bygger et innebygget sete, flytt en lenestol dit, vent noen dager, og se om du liker å sitte der
  • Barn elsker små huler

Disse mønstrene spenner fra byplanlegging («spre de eldre ut i samfunnet», «skap områder der folk kan henge») til interiører («møblér aldri et rom med like stoler»). Boken bærer preg av å være en en reaksjon på 60-tallets brutalisme-arkitektur, men sier i alle fall noen om brukergrensesnitt og fundamentale, sunne prinsipper innen konstruksjon – enten det nå er bygninger eller systemer. Jeg underviser til tider i en bygning der håndkleautomaten står slik til at nestemann som kommer inn på toalettet slår døren i ansiktet ditt. Når jeg ser enkelte ERP-systemer og webportaler slår det meg at ganske ofte er det ikke noe poeng i å være original – og at det som fungerer og folk er vant til, ganske ofte er det man bør bruke.

Systemer er alltid i endring, og ingen premierer deg for å finne på noe nytt bare for å lage noe nytt. Som regel handler de om å fjerne friksjon – både for brukeren av systemet, men også innenfor den oppgaven systemet skal gjøre. Hva om vi bygget systemer der hovedoppgaven var å lære, dag for dag, hvordan fjerne mer og mer friksjon?

Del
Kommentarer:
Du kan kommentere under fullt navn eller med kallenavn. Bruk BankID for automatisk oppretting av brukerkonto.