Hvordan håndterer du teknisk gjeld?

Programmering
#1

Kom over en veldig fin artikkel om teknisk gjeld som definerer konseptet på en litt annen måte enn det jeg har sett før. Det er faktisk sånn det ble definert første gang, av han som fant opp begrepet.

Et lite utdrag:

When you choose an iterative process, you use that time to deliver several partial solutions. You don’t understand the full requirements until the last iteration, so for most of the year, the ideas in your head are partial. The code embodies your partial understanding because it cannot be more insightful than the ideas in your head. The original paper argues that this is ok, as long as you don’t leave the code in that state forever, and it introduces the debt metaphor: “Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.”

Dette er altså noe annet enn bare dårlig kode, eller kode som skrives dårlig med vilje fordi man planlegger å fikse det senere. Det handler om at koden er dårlig fordi du (helt uten mulighet til å gjøre noe med det) ikke forstår problemet godt nok enda. Med en iterativ utviklingssyklus er det omtrent uunngåelig å havne her.

Så mitt spørsmål er: Hvordan håndterer du/dere kode som ble skrevet mens du forstod problemet for dårlig?

1 Like
#2

Hmm, veldig interresant spørsmål. Det som jeg syntes er veldig fascinerende er hvor rådende teknisk gjeld er i alt som har med software utvikling å gjøre. Det er et fenomen som finnes i samtlige prosjekter, nermest fra dag 1. Og det er ikke et problem man har en praktisk løsning på, selvom det finnes flere ting som hjelper minimere effekten av fenomenet. Det er vel kanskje litt som hvordan økonomien i dag bygger vekst, som igjen er helt avhengig av at noen tar på seg gjeld (Juval Noa Harrari forklarer dette veldig fint i Sapiens syntes jeg).

Det jeg tror er den mest effektive måte å håndtere dette på er en mentalitet om et stykke kode aldri er fullverdig, i alle fall ikke sammensettningen av en kodebase (altså kan noen funksjoner alltids stå seg over tid og være et riktig bilde av virkeligheten på en måte). Dette er noe boken “Refactoring” av Martin Fowler går litt inn på.

I tillegg tror jeg man må ha en pragmatisk tilnærming til når et stykke kode er “god nok”, når man aksepterer at koden aldri blir helt perfekt for det som bygges på i fremtiden. Noe som Andrew Hunt og David Thomas tar for seg i boken “The Pragmatic Programmer”

Ofte tenker jeg på programmering litt som husbygging, hvor man benytter en bråte ulike verktøy for å konsturere først et “rammeverk” som skal støtte en ønsket brukerflate. En grunnmur med en grunnflate på 50 kvadratmeter har begrensinger for fremtidige “features”, på samme måte som grunnen man bygger på (fjell/jord/leire etc.) også setter noen begrensinger for både levetid, høyde på bygget osv osv.
Forskjellen i programmeringsyrket er at vi hele tiden får nye grunnforhold å forholde oss til, vi har ikke bare fjell (datamaskiner), leire (telefoner) og jord (internett), vi får også klokker, mikrobølgeovner, kjøleskap, biler, tv’er, og hvem vet hva som kommer i fremtiden som man ønsker å kapitalisere på i sin løsning. I tillegg får vi ikke bare nye verktøy (både språk, men også rammeverk og paradigmer), men verktøyene endrer seg og forsvinner, og vi må kontinuerlig lære oss å bruke ett verktøy. (Kan man sage så kan man sage, det blir ikke så veldig annerledes over tid, selvom man kanskje blir flinkere til å bruke saga over tid).

TL;DR: Akseptere at koden man skriver aldri blir perfekt og ta litt takke med hva som er good enough på et gitt tidspunkt.

NB: Med good enough mener jeg ikke at man skal stoppe selvom man fortsatt ser forbedringspotensiale som fortsatt er relativt enkelt å utføre.

1 Like
#3

Dette med at koden sjelden er ferdig er jeg enig i. Det er mye som endres over tid, både eksterne ting som teknologi, leverandører, partnere, kunder, men også din egen forståelse av problemet som nevnt i første posten.

Refaktorering løser alle problemer

Man kan, som du sier, betale inn gjelden ved å refaktorere koden. Men når og hvordan refaktorerer man? Personlig liker jeg å lese kjapt gjennom koden før jeg begynner på en ny feature. Hvis nødvendig refaktorerer jeg koden slik at det blir lettere å legge inn den nye featuren.

En quote fra Kent Beck

make the hard problem easy then solve the easy problem

Og oppfølgeren:

One aspect of “make the hard problem easy then solve the easy problem” is that sometimes you can’t imagine how to make the hard problem easy. Hitch up your britches and solve the hard problem. But then look back & see if now you can see how you could have made it easy.

Nei, refaktorering løser ikke alle problemer

Det finnes en del problemer som ikke “bare” kan refaktoreres. Eksempler er databasestruktur, to micro services som skulle vært én, etc. I noen tilfeller synes jeg det er bedre å la den eksisterende løsningen dø, for så å bytte den sakte men sikkert ut med en ny en. Dette blir mer en rewrite enn en refaktorering. Ulempen er at software har en tendens til å aldri dø helt, så man bør ha en strategi for det endelige dødsstøtet.

Det er også all den koden som ikke får nye features. Med min strategi om å refaktorere kode før jeg legger inn en ny feature er det enkelte biter av kodebasen som blir veldig gamle før de blir refaktorert. Hva gjør man med disse? Her tror jeg en bedre strategi er å ta jevnlige gjennomganger av gammel kode. Vårrengjøring med andre ord. Da får man i hvert fall rydda unna de verste synderne.

Jeg er glad for at du skilte mellom disse. Poenget er at “good enough” er løsningen som løser det nåværende problem på en best mulig måte, men som ikke tar høyde for fremtidige features hvor man ikke vet hva beste løsning på problemet er. Her er det selvfølgelig gradsforskjeller i hvor sikker man er på hva som kan dukke opp i fremtida.

1 Like
#4

Min vei er at jeg alltid vil se hvor vi skal havne til slutt, så begynner vi på veien dit. Vi må legge veien der man slipper å lage for lange tunneler og bruer. Ta gjerne en liten omvei, men prøv å kom raskest mulig tilbake til den planlagte ruta.

Når du er fornøyd, har du kanskje tilbakelagt tredjepartern, fremdeles langt igjen men du ser mål. Det kan ta tid.

Veien du har lagt må du vedlikeholde. Det er slitasje, men du har ikke bygget svære bruer eller tunneler som er dyre å vedlikeholde. Alle ser veien din tydelig og greit, og du vet hva du har, du har til og med kommet dit du ville uten dyre konstruksjoner.

Så fort du har begynt på veien, så har du gjeld. Du må vedlikeholde. Ønsker du ikke gjeld, la være å begynne på veien.

2 Likes
#5

Blei tilsendt den her angående software engineering i google:

Det er et interessant kapitell om teknisk gjeld:

2.11. Frequent rewrites
Most software at Google gets rewritten every few years.
This may seem incredibly costly. Indeed, it does consume a large fraction of Google’s
resources. However, it also has some crucial benefits that are key to Google’s agility and
long-term success. In a period of a few years, it is typical for the requirements for a product to
change significantly, as the software environment and other technology around it change, and
as changes in technology or in the marketplace affect user needs, desires, and expectations.
Software that is a few years old was designed around an older set of requirements and is
typically not designed in a way that is optimal for current requirements. Furthermore, it has
typically accumulated a lot of complexity. Rewriting code cuts away all the unnecessary
accumulated complexity that was addressing requirements which are no longer so important. In
addition, rewriting code is a way of transferring knowledge and a sense of ownership to newer
team members. This sense of ownership is crucial for productivity: engineers naturally put more
effort into developing features and fixing problems in code that they feel is “theirs”. Frequent
rewrites also encourage mobility of engineers between different projects which helps to
encourage cross-pollination of ideas. Frequent rewrites also help to ensure that code is written
using modern technology and methodology.

Føler dette er spot on, men det sitter nok langt inne for de fleste organisasjoner å gjøre noe sånt. Lurer på hva de mener med “rewrite”. De sitter jo på en masse data, og de kan vel neppe skrive om datamodellen hele tiden?

2 Likes
#6

Oi, det er skikkelig kult å høre at de faktisk gjør det her. Spesielt tøft at de tar med dette i begrunnelsen for å gjøre det:

Det har jeg skikkelig trua på.

1 Like