Dealing with Inherited Data and Code?

bhima asks: "Recently I have inherited an embedded project which developed and maintained by a recently acquired company. The 'technology transfer' consisted of me traveling to their facility for two weeks of special high intensity training and returning with a couple of hard drive, equivalent DVD-ROMS, 200 kilograms of paper and a stack of tape backups. These contain a lot of interesting and important data but it is in every conceivable format: hundreds of megabytes of Outlook PST files, Adobe PageMaker & Illustrator (4 different versions for Mac & PC), Gerber files, Microsoft Office files (every version ever), Visio Files, Tiffs, Jpegs, AutoDesk Files, Pro-E files. To top it all off they used no concurrent versioning system for their firmware so I have hundreds of tar.gz files that are snapshots of code, plus the resultant binary record for version represented by the tar file. We have a student translating all of the CAD data to our system, but that's only part of the story. Is there an easy way to get the firmware in to CVS or subversion? What's the best way to organize all of this data so that it's actually usable?"

Comments

Shove it into CVS

[TheSHAD0W]

I had a similar problem, and by taking the code snapshots in order and shoving them into CVS, it was a great help in figuring out what changes were done when and for what reason. Obviously not as good as a commented changelog per file, but better than nothing.

Re:Possibly not as bad as it looks

[Dr. Manhattan]

Going forward, your best way to understand what the software does now is by talking through it with the people you have access to, and using it (reading and commenting the code when you aren't sure what's going on).

My group inherited a bunch of code from another group; almost the worst possible situation (the original product was a prototype that had been shoved into production, the code was meant to be 'portable' but was never actually ported, and hence full of gotchas, etc.).

Ever read 'The Art of Unix Programming'? When he said, "The combination of threads, remote-procedure-call interfaces, and heavyweight object-oriented design is especially dangerous... if you are ever invited onto a project that is supposed to feature all three, fleeing in terror might well be an appropriate reaction.", he wasn't kidding. One of our guys found 1500 lines of code that didn't do anything.

The key thing is to figure out where the joints are. Find the interfaces, the ways different peices talk to each other. Understanding this is usually the key to how the whole code is organized. It tells you how the authors thought about it. And it also tells you what parts can be incrementally replaced without having to throw out the whole shebang.

Re:What we did in a similar situation...

[bhima]

"artifically providing job security"... While I try to always attribute things like this to stupidity or poor work habits. I have found several "events" in each device's documentation or source that appear almost like one thread in a giant tapestry has been singled out and purposely removed. Usually it's subtle and a few weeks archeologist work (and a little assembly coding) resolves it. But it always leaves an "on purpose" taste in my mouth. Still though it's fun in a perverse way and I would not be adverse to being a full time reverse engineer (if I ever have to find another job)

The first thing I did was hire summer students to convert all of the electronic documents, some of was challenging (as I described in another reply) but doable. All the kids are back in school now so it's a lot more quiet in my office & labs.

.

You're right though some days I do feel like I need a priest and a good deal of the refactoring juice