How do you approach undocumented code?

  • Evil Kraig F (10/7/2014)


    I've inherited tragedies similar to what you describe.

    My first step is to open Visio. My second step is cancel my meetings for a week.

    I create a hybrid DFD/Processing Diagram. I'm not sure if anyone but myself would get to that detail level but it's the only way I can keep something like that straight by the time I'm done. Go through the process, inch by inch, detailing everything.

    These are the kinds of diagrams you wallpaper with, so you know. They're overkill, and designed to be so. You can't see the patterns unless it slaps you in face, repeatedly.

    From there, I collapse the diagram. I figure out where reptitions are occuring (Transforming the data from location A in 8 different places without the original version(s) being needed between the steps), and determine the overall shape of the process. From that, I write up the functional rules and then the tech spec/definitions after the initial collapse of the obvious 'missed optimizations'.

    From those functional rules and specs, I put what I found into a nice coffin, bury it with honors, and start over.

    Timing is everything. I found out from my boss today that a fourth piece of software (this one not in-house) is being added to our environment that's going to drastically alter our folder structure. Basically we'll no longer be associating data with a specific job number, it will only tie back to client and project. That actually makes more sense, since data frequently gets re-worked and associated with multiple jobs anyways. After 180 days of inactivity the project comes down.

    So, I'm going to have to re-write everything to cope with that less granular approach.

Viewing post 16 (of 15 total)

You must be logged in to reply to this topic. Login to reply