Re: Learning Code...Fast

Why do you think this would not be interesting work? (leaving aside the fact that the OP clearly stated that he does have a financial stake in it.)

What gives you the idea we're all using Java?

Furthermore, experienced programmers work where they work for any number of reasons besides interesting work. Like benefits, working hours, money, nearby skiing, cute coworkers and freedom from PHB's

By financial stake I meant a profit/loss sharing potential. It's a great way to make an onerous task look interesting.

Let's see now - 100,000 lines of old code, no documents, unrealistic schedule. The silver lining - the opportunity to discover some subtle bugs, which then become your problem. Which part of it excites you?

-- Joe Legris

Before touching one line of code, ensure you have the complete tool chain to recreate the original, and to check that the result is bit for bit identical. Only after that can you afford to revise the source and tool chain.

Then do cosmetic revisions on the source. The thing that stands out is the 'magic numbers'. There is no reason for these, they should be properly defined with meaningful names. Such things as consistent indentation and naming conventions can be inserted here. These revisions can be checked for identical binary outputs.

If it doesn't exist, build a regression tester that can be easily and automatically run.

Now you are ready to make real progress rapidly. The up front work will pay off, and you will find yourself able to make bolder and bolder revisions as your understanding increases.

Unless *you* get to decide what the word "possible" in that sentence is supposed to actually mean, accepting that job would appear suicidal, to me.

"so there" implies the latter is a direct consequence of the former. Mildly speaking, that's not exactly correct. Just because it's an embedded system doesn't mean the code must be crap.

There are tools designed to help with that. Automatic source code analyzers that let you visually inspect the structure of the project. RedHat Source Navigator would be one such tool worth trying, as long as the actual source code is still parseable as C++.

As others have pointed out, timescale may be the biggest problem for you. These sort of things take as long as they are going to take. Offer no hard promises of when the end date might be as it will all depend on the quality of what you are inheriting (which, if documentation is lacking may be dubious).

There is no doubt but the first thing you will start doing is assembling whatever your detective work can find by way of real documentation. This means you finding the hardware data sheets, schematics, user manuals, any design notes that may still be around etc. You should also find the original compiler toolchain and recomp[ile the sources you find to ensure they are complete. If you can compile the whole lot then compare with the binary of a working unit (which I trust you will also have access to).

One other poster mentioned establishing a "war room" where you can hang the printed listings of the code and mark it up as you find out things. If the originalk author of this code has used a lot of magic numbers then put them in either a named constant of clearly identify them with a named definition of what they represent.

Don't forget, for your own sanity and the benefit of your paymasters, to establish a review process by which you can be assured that your efforts are progressing in the right diorection and they can see how the project progresses. This way they will usually wear longer timescales if they see progress being made but no way of helping to speed ity up.

Good luck if you accept the challenge.

I just meant that those who do use Java might be using Zinc instead. But I'll save it for alt.history.what-if.

I saw Zinc library in early '90. It was a rather impressive library of primitives for creating user interfaces under DOS (C compiler was not included). How could that library be possibly used as a programming language eludes me.

Vadim

I didn't mean that one implies the other. I happen to have seen the code! ;-)

Absolutely, positively, and beyond a shadow of a doubt, the most valuable tool I have used in these types of situations is "Understand for C/C++" by Scientific Toolworks, Inc.

I was introduced to it a few months ago on a 500K-line C program as a contractor/consultant and found it *so invaluable* that I (how's that electric shaver commercial go?) bought the product for my own toolchest for those other clients that dump their code on me and ask "how long will it take you to ________?". Now I have a tool that give me much more confidence in my Rough Order of Magnitude estimates for performing modifications without breaking something else.

-- Dan Henry

I have used this tool as well, and can also recommend it. It is also great for generating piles of documentation to keep certain types of QA people happy. (Here in South Africa there is a tendancy to use people who are useless at anything else for QA) It of course can also be used to generate very usefull documentation as well - hyperlinked to the actual source etc.

Regards Anton Erasmus