Ok, sedan jag började få betalt för att gräva i andra människors produktionskod för att fixa buggar jag inte själv skapat, har jag fått lov att förfina mina debuggingmetoder en aning. Det visar sig att de flesta bolag verkar tillämpa någon av följande för att strukturera sin avlusning (både i utveckling och produktion)

Debug

Intuition
Ok, har du skrivit koden själv och har 100% koll (vem har det?), så är det inte ovanligt att du har en såndär härlig magkänsla av vad det är som inte fungerar. Bra vid fulutveckling... Men... Denna metakunskap följer oftast inte med när utvecklaren slänger över ett installationspaket till operations och en kille i Birkenstock tar över. Inte alltför sällan leder denna approach till katastrof då att den slutsats man drog var felaktig från början...
Skippa!

Diagnostics
Detta bygger på att vårt kära debugging-offer emitterar tillräckligt med information för att  vi skall kunna diagnostisera och mäta. Inte helt vanligt. Av någon anledning är debug, trace eller perf-counters inte vanligt förekommande i produktionskod. Fattar inte varför... Känns som om detta fått en fulstämpel på sig av någon anledning. Tron på att allt skall fixa sig för att man har code coverage på några lama unittester verkar regera på många ställen... Synd...
Inkludera alltid en verbose switch för Trace och använd den!
Inkludera perf-counters för viktiga objekt
Etablera en Health Model (en hälso state machine) för applikationen redan i första iterationen.

"Leap Of Faith"
Ändra på något... Kolla om buggen försvinner... Repetera... Känns (helt allvarligt) som den vanligaste metoden därute...
Acceptera att detta är vanligt förkommande när någon annan kommer att felsöka din kod! Bli en av dem som lämnar träsket!

"Head In Sand" eller Strutsen
Hävda att det är ett specialfall som inte kommer att inträffa i "verkligheten", bli defensiv och försvara dig med näbbar och klor.

"Scientific Approach"
- Samla in information
- Analysera data
- Kicka fram en hypotes (och skriv ner!)
- Testa hypotesen (Våga inte ens tänka på att starta Visual Studio eller WinDbg och bränna tid innan ni nått hit)
- Upprepa

Jag blir alltid fundersam över driftsorganisationer och utvecklingsavdelningar som börjar skrika MINNESLÄCKAGE! och skicka iväg incidentrapporter, eskalera ärenden till problem managers utan att ens ha gjort ett försök till att använda den sistnämda metoden. Att etablera en process för hur en outsourcad driftsavdelning skall samla in data, analysera denna och kicka fram en hypotes borde vara insprängt i det kontrakt som etableras innan driftssättning. I detta dokument borde även definitioner på minnesläckage, bug, hög minnesanvändning, hang, crash och annat ingå. Annat jag skulle vilja se här är en lista på verktyg (adplus, WinDbg, DebugDiag) och hur dessa skall användas. Tänk vad mycket tid vi skulle vinna... Och vad mycket pengar vi skulle tjäna...