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
Given you don't know what the current codebase is like, that is BAD advice. If the code is moderately well written, the chances are that a total rewrite would not improve things much. In short, it would be a waste of time / money. Don't confuse poor software engineering processes with bad code.
Management types usually seem to think that source code per se is a precious commodity. You read hysterical quotes in the trade rags all the time about the dire effect of source code being stolen, etc. 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.
(Aside from being stupid and evil, software patents are pointless for this very reason. Even source code copyright is barely worthwhile.)
Mike
"Not an actor, but he plays one on TV."
Obviously I don't know the particulars of this project, but I've been in similar situations before.
My advice: don't worry about most of it. Don't throw it away(!), but don't go loading every revision from the past 3 years into CVS and converting every document to a readable, searchable format.
If the project was at a milestone (and the last code snapshot you have was fully tested), just load that into CVS and work from there. If it was in active development, maybe take a 5 snapshots and commit them in order, reviewing the diffs to get a sense for the direction things were heading.
If you can also get some tips for where to find the details on the features/changes that were "next up", that's also good -- but DO NOT take the time to read through the earlier documents and discussions. All that has changed by now; you'll just get confused. 99% of those docs are talking about software or features that didn't exist yet, and probably doesn't exist in the same form now, either. Do you have real changedates on the files? If you do that helps -- there may be a few documents that were actively updated and used (risk assessments, to-do lists, etc.) that might be nice to skim over. But software dev is a ceaseless process of change, so anything older than a few months is basically guaranteed to be obsolete and useless. Developers and managers keep this stuff as a CYA measure, or because "one of these days" they are going to update them and make them useful again.
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). Your best way to understand what functionality should be added next depends on where your company wants to go with it (which may not match up with the other company's plans...).
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.
Assuming the hardware and software are debugged and ready for production, start with the most recent stuff. Put it (source code, hardware schematics, mechanical drawings, compiler & build tools, etc) into Version Control and label it Release 1.0 Now you have a starting point that consists of everything you need to build this thingie and sell it. That should be your first concern.
It's a lot less important to be able to go back and look at earlier changes (note I said *less* important; not unimportant).
Next, start from the earliest archives and try to find actual requirements/specs. The point here is that now that you can build these things, you need to be able to test them and fix bugs, add features, etc.
After that, you can consider checking through everything else to see if it's worthwhile adding to the Product File, but at this time you may be into diminishing returns. Product requirements and current code are the two most important things to capture out of the total mess of files.