Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I think this is a fairly common and challenging topic for anyone that has ever inherited code from another programmer or team. I can think of two common scenarios in my professional career that I've run into; diving into an open source project, and strictly inheriting the code of an individual's project.

I'm coming up on the latter and will be inheriting a project created by an individual, and while thinking about how to best approach this, I figured I would ask for the intelligence of p.se so I can learn from your experiences.

When Magento (large scale eCommerce application) came out, I was really lost in the Zend framework. There was little documentation out during alpha, so it was hard to use the community resources. I ended up using grep a lot and back tracing methods to get a firm understanding of what it does. By doing that, I eventually learned more about the application design, although it did take a little while.

What is your approach when you're up against a project that has little documentation? I feel like it is almost finishing the painting of someone else, which is always an interesting task.

share|improve this question
Try eating their brain! :) That way you can consume all of their knowledge about the project. But be careful if anyone new tries to take over your project! –  FrustratedWithFormsDesigner May 2 '11 at 19:42
@FWFD I did that. It resulted in 25 years to life! –  Nic May 2 '11 at 20:10
D'oh! I guess you should've eaten your lawyer's brain too. –  FrustratedWithFormsDesigner May 2 '11 at 20:36
Is this individual still with the company? –  Dave Wise May 2 '11 at 21:18
@Dave Wise Nah. All the times this has happened it's been because the person had an episode or something. –  Nic May 2 '11 at 21:21

1 Answer 1

up vote 2 down vote accepted

Well, there has to be written down somewhere the intent of what the program or application is supposed to do. From there, you can get an insight into what the possible inputs and outputs of the program might be. When there is a problem, set a breakpoint and trace through the program. This will give you great insight into the overall program flow and if it is broken. I assumed a heaping pile of garbage four years ago. It is a POS application that cashier's use to process parking tickets. Four years later, it is working pretty well with some bugs still found here and there, but definitely easier to work with. Maybe it is easier to work with now because I am very familiar with the overall structure - I don't know. There probably are some comments to help guide you but maybe not enough to figure out why. That's where your debugger and IDE come into play in helping you inspect the value of member variables and examine the program in action.

That's the only advice I can give from someone who was in this very same boat four years ago.

share|improve this answer
yeah, I rely heavily on the debugger to give me an idea of what is going on. Going into it with no knowledge, did you have a reasonable amount of fear? I've found that at the beginning of any of these! –  Nic May 2 '11 at 17:49
@melee: When I switched jobs four years ago (and I am going through one now), I was a little afraid because the job required me to interact with devices over RS232 using C that I have never done. But within two weeks I had code written for a device driver to communicate with such devices. So while there is always a little fear initially, it is overcome as soon as you get comfortable with the code base. You need to take small pieces at a time and dissect them. There is no way you can tackle that much code at once starting from scratch. –  staticx May 2 '11 at 17:54

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.