Forensic Development

Debugging Detective Stories: Phill Haack

(Via Scott Hanselman.)

Phil has touched on something that I plan on Presenting at the Portland Code Camp. What my friend Brian and I call “Forensic Development”.

I’ve been writing code for about 10 years or so now and I think in that time I’ve written four applications from scratch. I’ve spent most of my time in the IDE, SQL Profiler, digging around in server logs, examining cookies on user machines, trying to figure out why this 5 year old application has stopped running or what the heck the last guy to touch the code was thinking. My other favorite is when someone decides that it would be easier for you to modify an existing off shelf application (or an OSS app) than it would be for you to write one from scratch. That is almost always untrue.

Here’s my original pitch to the Code Camp Yahoo group. If you’re in the Pac NW, be sure to sign up for the Yahoo group and come down. It’ll be a blast and “if you’re not careful you might learn something before you’re done…hey hey hey.”

“There’s always some old
application that’s been around for ever that someone
wants to add a new form to or print from. Or there’s
some software package that the IT dept purchased but
it doesn’t QUITE do everything they want so they
figure “Hey, you can just modify this right? All we
want to do is change this one thing, that’s easier
than writing it from scratch right?”. Which means that
you have to try and get inside this other developers
head and figure out how the app all fits together.
Where it’s “pain points” are and how to deal with
them.

Sometimes the old apps just stop working. Next thing
you know, you’re pouring over Apache logs or SQL
T-logs and event logs trying to figure out
a) when it died
b) what it was doing when it died.
c) How to get it running again before everyone gets
back from lunch and your phone starts ringing.

In a lot of ways, working on legacy code is a like
being a CSI. You might not have access to the source
code and somebody might have obfuscated the public
methods. So you start passing in random things and
looking for your arguments in the output.

Which reminds me, I need to write up a short blurb for the presentation.

  • http://haacked.com/ Haacked

    If I was in Portland, I’d definitely come to check it out.

  • Pingback: you've been HAACKED