Slashdot Mirror
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?"
What's the best way to organize all of this data so that it's actually usable?
:)
It really depends on your time requirements.
Personally, I hate writing documentation, but if you have time, you really need to write a migration plan. Basically you need to write down what all you have and what you want to do with it.
The migration plan should list all the milestones and even individual steps. This really sounds like a big project, not something you should spend a day or two on by cramming it into your system. This might seem tedious, but if you spend at least a few days organizing your thoughts and planning this, you'll save a lot of time later. The plan should probably also be passed around higher up, which means it should be readable, to make sure you're doing everything with the data and documentation that management wants.
Sounds like you'll be having fun for a while
Burn it all.
I agree heartily with about 98% with this, especially this part:
Serious practitioners know that source code by itself is virtually worthless--you need access to, and the good will of, the people that designed and implemented it. That's what's precious.
But if you do have to start reverse-engineering the product, the source code can be useful. Assuming that you can get it to build and run in a debugger, that is.
Or, if the code base contains a good automated test suite, that makes it very much worth the effort. Then you can trace the what of the code back to the why of the tests.
My advice would be to consider that you're starting the project from scratch.
The problem with this is there are probably a number of executives who think that by buying the psuedo-tangible assets, they've gotten a big leg up on a from-scratch project. I think your advice is accurate, but the poster is going to have a hell of a time getting the execs to have the same expectation. And unless he does, it's going to be a long slog of insane deadlines and disappointed bosses.
Personally, I'd consider this a fantastic time to update my resume.
I always wonder about the code quality I'd get out of developers who make these comments...
Source code *can* be worthless, and it *can* be extremely valuable. It all depends on the talent and good sense of the developers who came before. If the code is well-organized (even if it's not well-commented!), it's probably well worth it to keep it. Even if moderately heavy refactoring is required, you're still starting with a WORKING product. [I think -- hard to tell from the description]
In a business environment, that is *way* better than starting off with nothing. Look at Mozilla -- sure they got a sweet browser out eventually, years and years after scrapping the original Netscape browser and starting from scratch. But if they'd been a real company selling a line of browsers as their business, that decision would have destroyed them.
If you inherit good code, celebrate and learn. If you inherit bad code, write automated tests and refactor until you can understand what's going on. It'll be painful for a bit, but you'll be better off. Only if you inherit really abhorrent, non-functional software is a ground-up rewrite really the best choice.