Lazycoder

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.

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.

Keynote format
PowerPoint format
PDF format