Fog Creek Software
Discussion Board




Bootstrapping a project

I've just finished my first senior year at school and am about to start my fourth and final co-op term at a major semiconductor company, in the software applications group.  As would be expected, I'm going to be given an assignment, something to do with an existing system or chip.  This time around, I would like to try and optimize the time it takes me to get "traction" on the project and get real work done.

Usually when faced with the situation my insinct is to serially read as much documentation as I can or start from the main() routine of existing code and serially read the code from there.  I've always thought there must be a better way.

What do you do to get up to speed on a project?  Do you skim the available documentation and code to get your bearings and then attempt to make a trivial change? 

What are the things that you need to know to be "up to speed" on a project?  It seems to me the most important would be to know how to find the information you need.  To an extent, you need to have a mental Google for the project, knowing exactly where to go in the code or documentation or who to ask if you must.

In summary:  What steps do you take to get started?  What is important in becoming productive in a new project environment?  What do you study?  How much do you ask others?  When do you jump in?

Adam Keys
Thursday, May 09, 2002

1.  What is the state of the system before the program is
started?

2.  What is the state of the system after the program is
stopped?

3.  What are the major states of transition while the program
is running?

4.  Give me a test environment so I can step through it with
the debugger.

Johnny Simmson
Thursday, May 09, 2002

Stepping through with a debugger is the fastest way to get started (as stated above).  If you're doing kernel work, you may not have this opportunity - in that case, you may have to rely on kprintf's out the wazzoo to get you moving.  Watching the call sequence is a great way to get started.

Well written data sheets are a huge help.  Lucky (hopefully) for you, you should have access to full documentation which is so hard to come by these days.  I am mystified by the hardware manufacturers that consider their software and data sheets to be a closely guarded secret.  Anyhow, don't get mezmerized by the huge docs.  Don't stay in "read mode" too long - run the debugger.

Nat Ersoz
Thursday, May 09, 2002

Usually, when I look at a new project, the first thing I try to do is use it as a user for some time (I've been able to apply this in hardware scenarios as well, even though it usually is a bit harder or less "authentic" use). I try to use minimal documentation (hopefully, none at all) at this stage.

After I feel I've mastered the product in question as a user, I spend some time to do my own virtual design and implementation. By "virtual" I mean I don't actually produce the documents and code - I just get to the state that I don't have too many issues to close if I did have to write them. One of the things that I do try to get concrete about is performance/scalability numbers - how fast could these things be done in theory and in practice.

After I know how I would have done the same thing, I start reading the source, in no particular order. It may take a few reading to get the grasp of the entire thing, but I found that there's rarely a specific reading order that lets me grasp the details faster (except for reading .h files before .c/.cpp files, perhaps).

With that done, it's time to read the design docs, user manuals and just about every other documentation I can find; And then it's debugging time.

This order may seem weird, but I find it gives me the deepest acquaintance in very short time. It also exposes weaknesses or non-intuitiveness in the interface; Either suggests a better way to solve the problem or shows me a better way to solve problems and allows me to appreciate the system; Exposes inconsistencies between design, documentation and implementation. Most importantly, it avoids being lead astray by (possibly long prevailing) misconceptions.

When you look at a system top-down, you tend to assume it works - that is, in fact, the idea behind top-down design and implementation. When you look at a system bottom-up, you have to convince yourself that it works and have to be able to integrate the blocks to get the entire system functioning. Expectation mismatches are much more visible that way, less assumptions are made and more assumptions are verified.

Be sure to also evaluate competing alternatives. If you get a compiler as your project, also learn gcc, lcc and friends. If you get an OS as a project, find a relatively simple OS to study (e.g., AtheOS).  FreshMeat [ http://freshmeat.net ] is very helpful in finding open source alternatives.

Finally, never trust documentation, especially if it's internal. More often than not it is horribly out-of-date with the "truth"  available only as corridorware (meaning, you can find it in corridor talks and people's mind but nowhere else)

THE TRUTH IS OUT THERE. TRUST NO ONE.

Ori Berger
Thursday, May 09, 2002

*  Recent Topics

*  Fog Creek Home