Jeg har i de siste dagene (i tillegg til å handle hus), vært så heldig at jeg har fått gjøre det som er få utviklere forunt. Vi hadde ei lita glippe mellom releaser, og jeg har tillatt meg / fått tillatelse til å rydde i kode – som burde vært røsket opp i for lenge siden. Ettertiden får bedømme om jeg har gjort et bra stykke arbeid eller forårsaket et bra stykke merarbeid for mine kolleger, men jeg har ihvertfall hatt det moro. Det føles omtrent like godt som når du begynner å skimte konturene av gulvet når du rydder opp etter ungene (og deg selv…).

Normalt så drives prosjekter fremover av funksjonaltitet. Krav spesifiseres av forretningsressurser. Teknikerene skriver tester og implementerer. Testlinjene verifiserer så at ting henger sånn tålelig sammen før det settes i produksjon. Dette funker forsåvidt ok – helt til prosjektene blir lange og kodebasen blir stor.  Da skriker koden sårt etter vedlikehold, og det er av en eller annen grunn få organisasjoner som evner å se konsekvensen av å ignorere skrikene.

Mengden av penger som ramler inn i et prosjekt er en funksjon av – wait for it – “funksjonalitet” som kan leveres til en gitt deadline. Kunden driter i om det er vanskelig eller lett å lage funksjonaliteten. Det er den de betaler for og det er den som gir dem forretningsverdi.

Kode som ikke aktivt forvaltes parallelt med endring/innføring av funksjonalitet, blir med tiden “innfeit” og kreftsyk. Den krystallklare luften du engang kunne beskue tindene av elegante strukturer gjennom er blitt tett og ugjennomtrengelig av forurensning.  Tankene som en gang måtte ha vært lagt til grunn er umulig å rekonstruere. De har for lengst forduftet bak horisonten – sammen med de opprinnelige utviklerne

Symptomet på “innfeithet” er gjerne at det kreves enorme mengder innsats, penger og dødsforakt, som kun et fåtall utviklere er begunstiget med, for å gjøre selv den minste endring i koden, uten at en må leve i frykt for å bli skutt i bakhodet en lørdags kveld – av en sideeffekt som valgte å propagere opp av myra et par uker etter release. Ting blir dyrere enn de burde ha vært, men samtidig må de i en prosjektorganisasjon løses innenfor de funksjonelle rammene. Å spørre etter mer penger for å “reparere” kode en har laget selv og allerede levert er vanskelig.

Rockstar-groupiene nikker sikkert gjenkjennende nå. Hørte jeg noen som sa “kohesjon” og ”kobling” ?. Svært få utviklere tør å protestere hvis en fanboy skriker “Dårlig kohesjon! Ikke rart det går til hælvete!?! Har du ikke hørt om S’en i SOLID ?!?. Vi er jo fagmenn ! Vi skal kunne sånt”.

Yeah, right … Det er nesten litt søtt.

I en forsamling vil som regel alle utviklere med respekt for seg selv nikke anerkjennende og tilsynelatende gjenkjennende til sånt – samtidig som de innerst inne ber en stille bønn om ikke å bli hørt i prinsippene, eller gud forby få et spørsmål fra podiet om hva kohesjon egentlig er for noe.

Jeg skal hive ut av meg en påstand.

Det er kun et fåtall av de som til daglig arbeider med utvikling av programvare som har noe som helst forhold til metrikker og designprinsipper. Jeg sier ikke dette for å fornærme kolleger, men svært mange programmerere (inklusive meg selv, hvis jeg er uopplagt eller skulle mangle inspirasjon en dag) ser på dette som en jobb, ikke en religion. De sikter seg derfor inn på den ene metrikken de og lederne deres er opptatt av, dvs “kortsiktig virk”. Det er dette de blir målt på. Det er dette som betaler fredagspilsen og prosjektlederbonusene. Det er dette som gir stjerner i boka på styringsgruppemøtene – dessverre.

Jeg kjenner en del som er dyrisk opptatt av metrikker, designprinsipper og om pilene i siste UML-profil skal være stiplede i en eller annen kontekst. Dette er vel og bra for blind intellektuell vold mot tilfeldige forpipasserende ved kaffemaskina, men for å løse utfordringen med “vedlikeholdbar programvare i praksis”, så er metrikker og designprinsipper i stor grad er irrelevante.

Jepp, du leste riktig, og rasjonalet mitt er som følger:

1. Funksjonalitet er i praksis lokal – dvs det finnes ingen mekanismer for å unngå redundans, utilsiktet kobling pga misforstått gjenbruk, samt tap av kohesjon i kode så lenge du ikke krever at samtlige utviklere har eierskap til (og full forståelse av) all kode, samtidig som de kontinuerlig refaktorerer ting som er utenfor scopet deres – på idealistisk grunnlag. (yeah, yeah, jeg vet hva fanboys’ene sier, men i praksis så _er_ det “min” og “din” kode når du kommer over en viss størrelse. Grow up !)
2. Selv om du staffer opp prosjekter utelukkende med rockstars, så vil koden råtne over tid pga pkt 1. I verste fall har du ved et uhell istedet staffet opp med cargo cult-medlemmer, da de til forveksling ligner – samtidig som de benytter mye det samme vokabularet (og da kan du like gjerne tenne på sjappa og starte på nytt).
3. Arkitektur defineres dessverre som regel som en initiell powerpoint som presenteres på kick-off (dvs irrelevant), eller de “litt mer tekniske” grepene som alltid må gjøres i bakkant av prosjektet for unngå å bli saksøkt av kunden når systemet står i sju stein. Er du involvert i det siste, så gjør du sjelden større omskrivninger for å gjøre koden vakker og mer vedlikeholdbar. Du fokuserer på “virk”, ikke endringsvillig og vedlikeholdbar kode.

Prosjektdrevet utvikling av funksjonalitet i en eksisterende kodebase medfører en verden av smerte (Hvis en er litt ondsinnet, så kunne en kalt dette iterativ utvikling, men jeg har ikke lyst til å bli oppfattet som reaksjonær…)

En del har begynt å dra frem ord som “craftsmanship” i et forsøk på å gjenvinne selvrespekten, samt skape en viss distanse til kolleger som ikke fikk med seg akkurat _den_ boka, men det hjelper så sørgelig lite å være i stand til å konstruere vakre katedraler av logikk, så lenge ingen er villige til å ansette vaktmestere for å vedlikeholde dem.