Termodynamikens andra huvudsats säger att “alla naturliga processer strävar efter att öka den totala oordningen i universum”. (Den kallas också för Entropilagen, eftersom “oordning” inom fysiken mäts med entropi.)

Det märks exempelvis på att värme sprider sig och fördelas jämnt i ett rum (kaos; maximal entropi), istället för att samlas i ett moln någonstans (ordning och reda; mindre entropi).

Man verkar kunna säga detsamma om barnens leksaker, som naturligt fördelar sig jämnt över hela huset. För att få tillbaka leksakerna i sina lådor och hyllor krävs fysiskt arbete, eftersom det går emot leksakernas natur att vara ordnade.

Jag vill hävda att det är likadant inom it-arkitektur: Det naturliga för varje it-systems arkitektur är att entropin successivt ökar tills systemet uppnår kaos och “dör”.

Exempelvis i form av en big ball of mud:

A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. … The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition.

Många bäckar små, blir en stor å

För att ge min hypotes lite mer “cred” kommer här ett citat av Robert Martin (“Uncle Bob”), som har skrivit kioskvältare som Clean Code, Clean Architecture och Clean Agile:

Sometimes the developers manage to maintain this purity of design through the initial development and into the first release. More often something goes wrong. The software starts to rot like a piece of bad meat.

Notera att it-arkitektur inte är så klar och tydlig som man skulle önska. Till viss del finns den i arkitektens huvud, till viss del i dokument som denne har lyckats klämma ur sig, och till viss del i källkodens komponenters uppbyggnad och avgränsningar.

Man kanske kan säga att o-ordningen kommer sig ur ett antal andra o-ord:

  • Ont om tid. När man är under tidspress har man ibland dels inte tid att förstå arkitekturen, dels inte tid att följa den.

  • Ovilja eller olater. Det är ofta besvärligare att följa en strikt arkitektur än att göra det enklast möjliga som löser uppgiften, eller att göra som man är van vid.

  • Okunskap. De minst skickliga utvecklarna kommer förstås bidra med mer oordning, eftersom de har svårare att skapa bättre lösningar.

  • Otydlighet. Även för en pedantisk systemutvecklare är det ibland svårt att följa arkitekturen, eftersom man inte alltid ser eller förstår den.

Istället för att göra optimala, eleganta lösningar, gör man ibland så kallade fullösningar. Ibland under förevändningen att “vi fixar till det där sedan”, men inte alltid.

Det är väldigt svårt för arkitekten att upptäcka alla dessa små överträdelser mot arkitekturen. Kodgranskning är den sista kontrollen, men det är ofta för sent för omskrivningar då.

Med många små, små steg ökar oordningen/entropin i systemet. Det är sällan någon enda förändring anses katastrofal, vilket också är anledningen till att de släpps igenom. Många bäckar små, blir en stor å.

Min poäng med denna artikel är att vi inte kan lämna arkitekturen åt slumpen. Om vi enbart fokuserar på funktionella krav, kommer systemet successivt bli allt mer ohanterligt.

Money, money, money

Arkitektur ska inte enbart ses som en teknisk fråga, det blir förstås i slutänden en ekonomisk fråga.

En modern och välordnad arkitektur ger nöjdare systemutvecklare och därmed mindre personalomsättning.

En kaotisk arkitektur ger stressade och missnöjda systemutvecklare, som till slut säger upp sig för att jobba med något roligare.

Citatet om “big ball of mud” ovan fortsätter så här:

Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.

När man till slut avbryter livsuppehållande åtgärder på sitt kaotiska system, inser man att man måste skriva om det från grunden. Det är förmodligen svårare och dyrare än du tror, och framförallt om de som förstår sig på det gamla systemet redan har sagt upp sig!

Hur förhindrar vi sönderfallandet?

Termodynamikens lagar säger att vi måste tillföra energi för att bromsa eller minska entropi/oordning. Alltså arbete, och i det här fallet arkitekturellt arbete. Jag tror att dessa arbetsuppgifter är avgörande:

  1. Var medveten om riskerna/problemen
  2. Utbilda teamet i arkitektur och låt dem vara med och besluta
  3. Städa upp med refactoring – kontinuerligt
  4. Utvärdera med statisk kodanalys

Var medveten om riskerna/problemen

Första steget kan vara att över huvud taget diskutera riskerna med en sönderfallande arkitektur, och vad det är som orsakar det. Enbart genom att ta upp en punkt till diskussion, kommer teamet bli medvetna och arbeta mer avsiktligt och bättre med det.

  • Ont om tid. Vi behöver en förståelse från produktägare, säljare och chefer att tidspress skapar teknisk skuld, som måste betalas tillbaka senare. Det som ser ut som kortsiktigt lätta vinster kan skapa stora långsiktiga kostnader. Här behöver också arkitekterna vässa sina argument.

  • Ovilja eller olater. Vi behöver diskutera syftet med en arkitektur och vad som händer när man slarvar. (Jag tror att erfarenhet är en god mentor. När man har varit med och sett system åldras och hur svårt det kan vara att jobba med ett förfallet system, har man en större förståelse för hur viktigt det är att “göra rätt” från början.)

  • Okunskap. Vi behöver förstås rekrytera kompetent personal, men också ha löpande “fortbildning”, exempelvis med kurser, workshops och avsiktlig kunskapsspridning inom teamen. Det finns många kurser att gå online, och även Youtube har en hel del guldkorn. Teammedlemmarna själva vet säkert vad de vill lära sig mer om.

  • Otydlighet. Arkitekturen behöver tydliggöras och fastställas på något sätt, exempelvis med dokumentation, diagram och diskussioner. Detta underlättas nog av att det finns ett tydligt ansvar för arkitekturen. Kanske fråga teammedlemmarna vad som är otydligt? (Vänd på frågeställningen, så att du inte frågar vad de inte förstår, eftersom det kan upplevas som ifrågasättande av kompetens.)

Utbilda teamet i arkitektur och låt dem vara med och besluta

Som tidigare nämnts är kodgranskning bra men otillräckligt. Det är varken lätt eller meningsfullt att vid kodgranskning säga “gör om, gör rätt” – och dessutom upptäcks inte nödvändigtvis alla problem vid en granskning.

Alltså bör man diskutera arkitekturen tidigt i utvecklingsprojekten, för att maximera sannolikheten att man lyckas väl. Om man har en arkitekt, tekniskt ansvarig eller senior systemutvecklare, är detta förmodligen en bra samtalspartner.

Men det är förmodligen varken möjligt eller önskvärt att alla arkitekturella beslut på alla nivåer ska fattas av arkitekten själv. Det gör teamet och företaget personberoende, och låter heller inte systemutvecklarna nå sin egen potential.

Man bör istället utbilda teammedlemmarna och delegera beslut till dem. Det ger hela teamet större kapacitet och frigör tid till strategiskt arbete för arkitekten.

Detta kräver tid och energi av hela teamet, så det är inte självklart att det sker.

Städa upp med refactoring – kontinuerligt

Även om man har ett skickligt team, kommer arkitekturen sakta brytas ned, som diskuterats ovan.

För att hantera denna ständiga ström av teknisk skuld, behöver man allokera resurser för refactoring. Det är då man rättar till gamla misstag och förbereder för framtida projekt.

Jag tror att man behöver göra mindre refactoring löpande (motsvarande veckostädning), och boka in större omskrivningar mer sällan (motsvarande storstädning).

Detta arbete är kortsiktigt svårt att försvara ekonomiskt, men är en nödvändig kostnad för ett långlivat system.

Utvärdera med statisk kodanalys

För att synliggöra för alla att oordningen faktiskt ökar när man inte aktivt motarbetar detta, bör man införa statisk kodanalys. Detta blir ett objektivt mått som är svårare att bortförklara. (Annars blir det upp till arkitekten att lyckas övertyga chefen eller produktägaren eller vem det nu är att vi behöver mer refactoring – “nu igen?”.)

Statisk kodanalys kan läsa igenom källkoden och spotta ur sig mått på systemets kvalitet. Ett exempel är SonarQube och dess mått teknisk skuld. Själva mätetalet i sig är ointressant; det är trenden som är viktig.

Man kan sätta upp kvalitetsmål, som säger exempelvis att den tekniska skulden inte får öka, eller att den ska minska med X% per år.

Läs mer

Det finns tydligen ett par vetenskapliga (?) artiklar om detta ämne, även om de klokt nog inte verkar nämna termodynamik… Sök på “Software Architecture Erosion” om du vill läsa mer.