Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
"Ratios are for losers" var det stærkt provokerende kampråb, som jeg og nogle andre medlemmer af The OakTable Network benyttede i slut-90'erne og 00'erne for at få folk til at fatte, at de havde forsøgt at optimere it-systemer (især database-applikationer) på en komplet forkert måde.
Kort fortalt er det ligegyldigt, hvor mange fysiske versus logiske læsninger du laver per sekund i systemet, hvis applikationen kører godt - eller hvis den kører skidt.
Antallet af gange, noget sker, har ingen sammenhæng med tiden, som det tager. Det ved alle gifte mennesker.
Det afgørende er, hvor tiden bliver brugt.
På den ene og den anden side
Alle disse ratios med hundredevis af forskellige data trukket ud af databaserne og styresystemerne er blevet fremstillet på alle mulige og umulige måder i tidens løb, hvorefter "eksperter" har kloget sig i tykke bøger og lange foredrag om, at "på den ene side kan det være tegn på noget, og på den anden side kan det være tegn på noget andet - men det behøver bestemt ikke være et problem i sig selv".
Sådan udtaler økonomer sig konsekvent, fordi de kun har ratios at støtte sig til, og aldrig har stillet spørgsmål ved, om ratios er den rette måde at måle en økonomis performance på.
Mit favoriteksempel er dette: Du beder din søn på 19 om at køre ned på den lokale tankstation og købe en liter mælk.
En time senere kommer han tilbage med en liter mælk.
Du spørger ham ikke, hvor tiden er blevet brugt (og på hvad), men sætter dig i stedet og udtænker følgende strategi for, at det vil gå hurtigere næste gang:
1. Du køber en bil med kraftigere acceleration og tophastighed.
2. Du gør din indkørsel og garage bredere.
3. Du beder tankstationen om at stille mælken tæt på døren.
Gætterier i lange baner
I virkeligheden har knægten jo været ude og køre på motorvejen med kæresten i 55 af de 60 minutter, men det finder du ikke ud af, hvis ikke du identificerer, hvor tiden er blevet brugt.
Og det er præcist sådan de fleste "optimeringer" og "tuningsøvelser" foregår i dag.
Det er det rene Gæt & Grimasser. Ofte udført af en "task force", der forstærker hinandens stemninger og fordomme, men ikke insisterer på videnskabeligt verificerbare konklusioner.
En god test for eksperter er altid denne: Præsentér to superdupermotherfuckereksperter på et bestemt område for en masse data og ratios og bed dem konkludere i hvert sit aflukke.
Hvis de konkluderer forskelligt på de samme data, er det enten fordi, at deres metode er i Monte Carlo-kategorien, fordi data reelt er ubrugelige, og/eller fordi de gætter og grimasserer.
Men det kan udnyttes!
En af OakTable-medlemmerne - Connor McDonald - lavede et lillebitte PL/SQL-script, der kunne give brugeren lige præcis den BCHR (Buffer Cache Hit Ratio) som denne ønskede.
Bosserne ville have høj BCHR
Vi fandt nemlig ud af, at dårskaben mht ratios udstrakte sig til folk, der fik bonus baseret på, at deres databaser havde en BCHR større end eksempelvis 90.
Det har intet som helst med noget som helst at gøre, men eftersom bosserne ønskede en høj BCHR, fordi alskens eksperter - og Oracles Tuning-manual - sagde, at en høj BCHR var fantastisk, var det jo bare at lave en oneliner, der læste den samme databaseblock et par millioner gange og på den måde hev ratioen op til det ønskede.
Ingen applikationer kørte bedre, men database-administratoren og hans boss fik mere i bonus.
Minder lidt om de hjernedøde bonusser, som man udbetaler til en masse ubrugelige og uduelige chefer i det private og offentlige, fordi de opnår nogle bestemt mål, der ofte er simple ratios - fordi simple ratios er nemme at måle.
Hvorimod tilfredsheden hos dem, der skal bruge deres skidt, pudsigt nok er MEGET vanskelig at måle - nu på 200. år.
I min tid i ledelsen i Oracle sad vi chefer hvert år og manipulerede eksempelvis spørgeskemaerne fra kunderne (og/eller medarbejderrne), indtil deres svar passede med den ratio, der ville give os vores bonus for kunde- og medarbejdertilfredshed.
Visse tilfredsheds-skemaer blev dømt "outliers" og udelukket, når der skulle udregnes gennemsnit, for eksempelvi Vi fik bonus hvert år.
Når altid det, som man bliver bedt om at nå
Man når altid de ratios, som man bliver bedt om at nå, men det er aldrig til kundernes fordel, og det sker altid på måder, som ikke kunne forudses.
Kan man bruge denne viden om ratios til andre ting nu om dage?
Ja, man kan vel bruge det til at snyde alle de algoritmer, som det offentlige - og de private - slipper løs på os.
En af mine veninder i USA har arbejdet i Navy Intelligence i en del år, før hun fik et godt job som sikkerhedschef i en større biks.
Hun har tre gode veninder med tilsvarende baggrund.
De fire bindegale mennesker (med rimelige IQ'er) samles ind imellem med en god flok rødvinsflasker med indhold, og så sidder de ellers og søger på Google på så åndssvage, vilde, vanvittige og perverse ting, at Google-algoritmen overhovedet ikke er i stand til at finde ud af, hvad de egentlig kunne tænke sig at købe.
Jeg håber, at jeg en dag kan være en flue på væggen, mens den seance finder sted.
Baserer sig på statistik
Algoritmerne i de offentlige systemer (og de private) baserer sig på statistik.
Machine learning er jo blot automatiseret statistikopsamling, og rigtig AI findes reelt ikke endnu.
Og statistik er udelukkende ratios.
Ergo: hvis man kan få dokumenteret algoritmerne, kan man lave tricks med dem, ligesom Connor gjorde med BCHR-scriptet.
Og jeg synes ikke, at det er forkert at tænke på algoritmerne som værende lidt ligesom mennesker, det vil sige som menneskelige sagsbehandlere - nu med en masse data ved hånden.
Menneskelige sagsbehandlere kan påvirkes. Så kan algoritmerne også.
Måske skal der bare liiiiige en ekstra indbetaling på 42 kroner til, og SÅ er man ovre i en meget bedre kategori hos Gældsstyrelsen?
En god forretning?
Jeg kunne forestille mig, at nogle kvikke hoveder kunne lave en god forretning og få sig nogle gode grin undervejs på at hjælpe folk med at spille mere succesfuldt på offentligt anvendte algoritmer og dermed opnå alskens fordele, og måske endda slippe for, at det offentlige kontakter dem overhovedet, fordi de smyger sig under radaren.
Hvad med et game, der er en simulator, hvor du prøver at forøge dine chancer overfor det offentlige?
Jeg agerer MEGET gerne nogle workshops om disse forretningsidéer og giver MEGET gerne den første runde.
Det kunne også derfor være stærkt, hvis den kode, som NCHammer og de andre Big Ones udvikler til det offentlige rent faktisk så også tilhørte os, der har betalt for dem - open source på alle måder - for så kan man jo også se, hvad algoritmerne laver af numre, inklusive at samle alskens ting op fra Myndighed X og kombinere det med ting fra Myndighed Y og på den baggrund konkludere, at dine nummerplader skal klippes.
Tilbage til korrekt optimering:
Hvis man bruger for mange penge på mad og skal spare på husholdningsbudgettet, så er der nogle, der vælger kun at købe én leverdreng fra Stryknin i stedet for to per måned, men vedbliver med at drikke en flaske rødvin hver aften til maden.
Andre kigger på, hvor pengene reelt bliver brugt og skærer ned dér først.
Langt, langt de flest optimeringer og tuninger indenfor it foregår på Gæt & Grimasser-måden, hvor man prøver det ene, og man prøver det andet, og så håber på, at noget måske går bedre.
Det skyldes, at mange it-systemer overhovedet ikke er tids-mæssigt instrumenterede.
Ingen bruger det
Hele IBM's mainframe-platform blev instrumenteret til dette formål tilbage i 1980'erne. Oracles database blev instrumenteret i 1990'erne. SQL Server fik jeg faktisk instrumenteret i SQL Server 2008 og 2012 (tak til Johannes, Gram og Raoul).
Men ingen bruger det, fordi de gamle Gæt & Grimasser-folk stadig dominerer i Microsoft-verdenen.
Ingen it-applikationer instrumenteres på denne måde, selv om det burde være et krav.
De fleste OS'er er komplet håbløse på dette område. Alle netværksanalyser baserer sig på et VÆLD af ratios - det er derfor netværksfolkene ALTID svarer "der er ingen problemer med netværket", når man har problemer.
SAP har rent faktisk en instrumentering, men foretrækker KIWI-metoden (Kill It With Iron), fordi det sælger flere af deres licenser.
Jeg krediteres med at være den første manager globalt i Oracle Corp, der indførte, at tids-baserede målinger var den eneste metode, som mine folk måtte bruge, og det bredte sig jo heldigvis.
Oracle Wait Interface
Jeg/vi kaldte det The Oracle Wait Interface, men det er faktisk et dårligt navn.
Den førende ekspert i verden på dette felt, og en fyr, der nu også har taget hele konceptet til næste niveau, så alle kan bruge det i mange sammenhænge i deres liv, er min nære ven Cary Millsap, og hans seneste bog FASTER er guld værd.
Til gengæld er den sjov at læse. Men billig. Det må man så leve med. Bare køb den.
Jeg ville ønske, at mange flere ville stille spørgsmålstegn ved alle de hersens eksperter, der hver dag bombarderer os med ratios a la BNP, gennemsnitshusholdningsbudgetter, regnskabsnøgletal og andet sniksnak.
Hvis en bunke på 1.000 sten vejer et ton i alt, er det sgu' svært at vide, hvad den eneste røde sten vejer. Men alle økonomer vil fortælle jer, at den vejer et kg.
Måske skulle vi i stedet have sagt "ratios are for losers, crooks, and poor folks who don't know any better."
Kom nu frem - jeg hører gerne fra jer
Jeg hører gerne fra folk, der vil lege med idéen om at gennemskue algoritmerne og vende dem mod magthaverne ved hjælp af simple tricks.
Jeg forestiller mig stiftende generalforsamlinger med øl og den slags.
Og jeg hører også gerne fra folk, der har skønne eksempler på taber-ratios og alle de uvidenskabelige gætte-måder de anvendes på af eksperter overalt.
Jeg tænker også, at en del udviklere rundt omkring kan give gode råd til, hvordan de algoritmer, somde har smidt rundt omkring i systemerne, kan bruges på en, ahem, kundevenlig måde...
Jeg lytter på mogensxy@gmail.com, @mnorgaard på Twitter og andre steder.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.