Varför uppstår överdesign i mjukvara?

I mitt förra inlägg pratade jag lite om överdesign och att det faktiskt också är en form av teknisk skuld som vi gör bäst i att hålla borta från våra system. I detta inlägg tänkte jag titta närmare på orsakerna till varför överdesign uppstår.

Jag tänker använda tekniken med “5 varför” för att försöka bringa litet klarhet i frågan om varför överdesign kan uppstå. Syftet med denna teknik är att försöka hitta rotorsaken till varför något inträffar och inte bara de på ytan synliga. Detta gör man genom att fråga sig själv “Varför?” fem gånger.

1. Varför uppstår överdesignade system?
– Inte av sig själv. Därför att någon inför element som leder till överdesign, eller ser till att någon annan inför dem.

2. Varför skulle någon införa element som leder till överdesign?
– Första orsaken: Därför att personen tror att designen måste vara hållbar för framtiden, att man måste “ta höjd” för ditten och datten.
– Andra vanliga: Därför att det är frestande att göra en “snygg design” om man inte programmerar utan kan ägna mycket tid åt att tänka ut snygga lösningar.

Ok, två vanliga orsaker. Vi får dela upp oss i två spår härifrån. Låt oss börja med framtidsaspekten:

3.A Varför tror en person att design måste vara hållbar för framtiden?
– Därför att denne inte förstår TDD, refaktorisering, evolutionär design och andra moderna arbetssätt för programmerare på djupet. Att man faktiskt kan låta den rätta designen växa fram och inte behöver skapa en perfekt sådan från början.

4.A Varför förstår en person inte moderna, programmerarnära arbetssätt?
– Vanligtvis därför att personen inte har någon egen erfarenhet av dem samt att det inte finns någon erfaren programmerare i närheten som kan denne kan lära av.

5.A Varför designar en person som inte har någon erfarenhet av moderna arbetssätt för programmering och varför finns inte personer som förstår detta på samma plats?
– Därför att ledningen inte har organiserat arbetet på det sättet. De belönar också duktiga programmerare till arkitekter som då inte ska behöva “hacka kod” längre.

Aha, det kanske i alla fall delvis är en organisationsfråga. Låt oss titta på det andra spåret:

3.B Varför är det frestande att tänka ut en “snygg design” om man inte programmerar?
– Teknisk orsak: Därför att om man inte programmerar slipper man ta hänsyn till “implementationsdetaljer”, vilket på papperet förefaller vara detaljer men som kan visa sig påverka hela lösningen.
– Humanpsykologisk orsak: Därför att komplicerade designer förefaller imponerande på andra personer som vi känner behov av att imponera på, våra likar och våra chefer.

Oj oj, återigen får vi förgrena oss i två spår:

4.B.I Varför skulle en person slippa att ta hänsyn till implementationsdetaljer?
– För att slippa undan konsekvenserna av designbeslut måste designern vara avskild från personerna som ska implementera lösningen. Personen är alltså inte medlem i själva utvecklingsteamet.

5.B.I Varför finns inte personer som förstår god design och programmering på samma plats, i samma team?
– Därför att ledningen inte har organiserat arbetet på det sättet. De belönar också duktiga programmerare till arkitekter som då inte ska behöva “hacka kod” längre.

Aj då, samma svar igen. Låt oss följa den andra delen av det andra spåret:

4.B.II Varför förefaller en komplicerad design att vara mer imponerande?
– Ett ganska mänskligt drag, men också därför att personer inte kopplar designen till det behov den ska lösa. De som har behov förstår inte design och de som kan design är inte så intresserade av behov. Behov och design är frånkopplade.

5.B.II Varför finns inte personer som förstår behov och god design på samma plats, i samma team?
– Därför att ledningen inte har organiserat arbetet på det sättet.

Man kan diskutera denna analys, men enligt den här analysen skulle alltså rotorsakerna gå att finna i hur vi organiserar och belönar våra medarbetare. Det är alltså ett systemproblem som enbart kan lösas av ledningen och inte kan lösas av individuella medarbetare.

Precis som analysen ovan antyder är ett vanligt antimönster att alla erfarna systemarkitekter samlas i en separat arkitekturgrupp som mest dikterar villkoren för teamen och bara sporadiskt besöker dem för att släppa lite nya dekret.

Detta är olyckligt på många plan. Systemarkitekterna skulle behöva fortsätta utvecklas och förstå implementationsdetaljer. Inom programdesign bor djävulen i detaljerna, som man säger. De unga programmerarna, å andra sidan, behöver utvecklas till goda designers. Tyvärr fråntas de möjligheten att se experter i arbete på nära håll då experterna snabbt lyfts ur teamen. Enligt mig är en bättre lösning att göra precis tvärtom: Låt arkitekterna deltaga i teamarbetet och i stället regelbundet samlas och dela erfarenheter med andra systemarkitekter.

Till sist behöver båda dessa roller förstå vad kravtrycket är på systemet och hur detta påverkar designen.  Den andra delen av denna analys kokar ner till att systemarkitekter utan kontakt med resonemang kring nytta, värde och behov inte har någon som påminner dem om vad som är viktigt och att saker och ting faktiskt kostar pengar. De blir förälskade i sin makalösa designkreativitet och det finns ingen bredvid som kan ruska om dem och skrika “Hallå!”. De bevisar sin kunnighet för sina arkitektkollegor med gigantiska utskrifter av komplicerade diagram och det finns ingen där som stampar med foten och kräver nyttig, fungerande mjukvara, nu!

Behov, krav, design, kod, test. Allt hänger ihop och all separation av dessa förefaller mig bidra till sämre kompetensutveckling och sämre system.