Det er dyrt at være fattig

I “Scarcity: Why Having Too Little Means So Much” undersøger forfatterne Sendhil Mullainathan og Eldar Shafir effekterne af mangel i bred forstand. En af konklusionerne i bogen er, at mangel fører til tunnelsyn og kortsigtede løsninger.

Et eksempel på en sådan kortsigtet løsning kan være, når personer med lån, der ikke kan betale deres renter, optager nye, dyre lån for at klare afdragene. Selvom personerne udmærket er klar over, at det kun øger problemet måneden efter, føler de ikke, der er andre alternativer. En vigtig pointe i bogen er, at deres valg i høj grad skyldes omstændighederne og ikke personerne selv.

Problemet med tunnelsyn og kortsigtede løsninger gælder ikke kun økonomiske forhold. Hvis det er tid, vi mangler, udskyder vi opgaver, der bedst kan løses nu og afleverer halvfærdige opgaver – velvidende at de før eller siden alligevel skal gøres færdige.

Ligesom der løber renter på ens lån, og gælden vokser, så bliver tidsforbruget på den enkelte opgave også større, når vi udskyder den, men lige nu og her er kan det føles som den eneste udvej.

På den baggrund er det ikke overraskende, at et projekt, der er presset af deadlines, nemt kan komme til at ’optage gæld’.

Og det vil ofte være en gæld, der skal betales tilbage på det allermest ubelejlige tidspunkt, fx når du står med en kritisk produktionsfejl i ulæselig kode kl. 8 tirsdag morgen, uden noget spor af, hvad der er sket.

Når man ovenikøbet har travlt, når fejlen viser sig, og gælden skal betales, bliver selve rettelsen “noget-der-får-det-til at gå væk-lige-nu-og-her” – og man har igen øget sin gældsoptagelse.

Indimellem kan det ikke undgås, at vi er presset af deadlines – om det er rimeligt og rationelt eller ej – men der kan fx være store forretningsmæssige omkostninger ved at udskyde en release.

Så må man låne…

Hvad gør man så som deltager i et projekt presset af deadlines?

Som i eksemplet med afbetaling af lån, kan der være mere eller mindre smarte måder at optage gæld på.

Først og fremmest bør vi være bevidste om den situation, vi står i. Nogen i projektet skal have overskud til at håndtere krisen og (tage initiativet til at) finde den bedste vej ud af den. Det lyder simpelt, men en af priserne for mangel er “reduceret båndbredde”, så det er ikke altid så enkelt.

Hvis det ikke er muligt at skære i funktionaliteten, bliver vi nødt til at gå på kompromis med kvaliteten.

I stedet for at lade vilkårligheden styre, hvor koden er gennemarbejdet, bør vi vægte både tekniske og forretningsmæssige hensyn.

Tekniske hensyn er først og fremmest:

• hvor mange andre dele af applikationen afhænger af denne del af koden?
• Hvor kompleks er koden?

Jo mere der afhænger af koden, og jo mere kompleks den er, jo vigtigere er det, at koden er af høj kvalitet.

Forretningsmæssige hensyn kan være:

• Hvor mange transaktioner løber gennem denne del af koden?
• Hvor kritiske er fejl?
• Hvem bliver berørt af fejl (kunder/interne)?
• Hvad er den forventede levetid?
• Hvor nemt er det at kompensere for fejl?
• Hvor sandsynligt er det, at der vil ske ændringer i kravene?

I vægtningen af de forretningsmæssige hensyn deltager forretningen selvsagt – og får på én gang både indflydelse og indsigt.

Og hvad kan man så lære af det?

I den perfekte verden vil vi altid gerne levere alt i højeste kvalitet. Men i virkelighedens verden bliver vi næsten altid nødt til at prioritere.

I et sundt projekt vil vi ofte have en god fornemmelse af, hvor der skal sættes massivt ind med gennemarbejdet kode, omhyggelige reviews og forbilledlig testdækning. Og omvendt ved vi, at det måske ikke er nødvendigt i det hjørne af applikationen, der primært bruges internt, og hvor nye versioner kan lægges på uden at genere nogen.

I et presset projekt er der risiko for tunnelsyn, hvor alle kæmper sin egen kamp, og vilkårlighed vinder over bevidste prioriteringer – og hvor forretningen kan konstatere, at den ene fejl afløser den anden.

Kan vi i den situation suge luft ind og vælge kreditforeningslånet i stedet for kviklånet, er meget vundet – og fejlen tirsdag morgen vil berøre nogle få interne, være nem at rette og ikke have andre konsekvenser end, at de berørte må prøve igen lidt senere.