Lazycoder

Forensic Development

A while ago a friend and I coined a term for what we end up doing most of the time when we get a new development gig. We usually have to go in and figure out someone elses code. Sometimes it’s legacy code that has been chugging along since the Regan administration and suddenly stopped working. Other times we’re called upon to upsize an Access database created by an administrative assisitant in their spare time. Mostly what we’re doing is either exploratory surgery on a codebase or, more likely, an autopsy. The only difference is we’re expected to pull a Doc Frankenstein and put all the parts and pieces back together into a living application.

Here’s the description I submitted for my Portalnd Code Camp presentation.

Have you ever been given an application and told to “make it work”? Have you ever had to extend an off the shelf application? During my forensic development presentation I’ll talk about some ways to find out what the code you are suddenly responsible for is actually doing. I’ll cover investigative methods and ways to tame old code as well as ways you can leave behind clues for the next developer. I hope to stimulate a short discussion about when it is appropriate to start over rather than hack away at a codebase.

So here’s what I’d like anyone reading this to do. Submit your best “I figured out what the heck this code was doing” story. Your best “Eureka!” moments while debugging or the most obscure error you’ve found. I don’t care what language or platform you used. Tell me about some of your favorite techniques. Places you look for errors first and last. Ways that you use to make the computer tell you what is really going on.