Whil, I think that the secret is in the documentation of the system(s) you do before beginning the project. In a word (or three) Design, Design and Design.
There is an excellent book called "The Pragmatic Programmer: From Journeyman to Master" by Andrew Hunt and David Thomas has some good reading in it regarding refactoring or generating code from projects that have been picked up again or from other people. Although not 100% relevant to your question but useful when coding in general, I particularly liked the following recommendations amongst some of my own: 1. Use the DRY Principle (Don't Repeat Yourself) Keep the low level knowledge in the code where it belongs and reserve comments for other high level explanations and simple diagrams. 2. Design Orthogonal Systems This effectively removes the "Effects Between Unrelated Things" and allows you to pick up projects/code without having to absorb the whole thing first, which is difficult after a layoff. In the book he describes a "non Orthoganal" system to be akin to a helicopter. Only three controls but they all have a mutual effect on each other. The collective moves you up and down but when you descend the helicopter moves its nose down and begins to rotate to spiral - a secondary effect. Lower the left hand lever and you then need to add compensating backward movement to the right hand stick and push the right pedal erc etc. Those of you who have tried to hover a helicopter will understand that it is a constant juggling act trying to balance all the interacting forces. Modifying a system designed in this way is consequently a nightmare - so stop it happening. Designing a project in layers provides a level of abstraction because each layer should only use the abstractions provided by the layers below it. 3. Keep your code decoupled Always ensure your code remains isolated from the implementation of other outside code 4. Avoid global data Not always possible I know, but a good rule of thumb to keep to if possible. 5. Always be critical of your own code Look for any opportunity to improve structure and the resultant code when revisited will require the minimum amount of modification. It is always more difficult to remember what you "thought you should do to code 6 months ago" as opposed to "what you have to do now" to improve a system 6. Testing Have a fully documented set of tests to carry out after any modifications. That way the "oh, I'll just add this code...I'm sure that it won't affect anything else" phrase won't come back to haunt you. 7. Use the "Tracer Bullets" technique As it says in the book "There are three ways to fire a machine gun in the dark" a. Find out the exact conditions, location of the target, specification of your machine gun and use the manufacturer's tables to calculate the exact elevation and bearing to fire on. If you estimated correctly you will hit the target. b. Close your eyes and spray bullets wildly in the general direction of the target - how many systems have you seen where this is the norm? or c. Use tracer bullets These are bullets loaded onto the ammo belt at intervals which burn phosphorous when fired and "glow in the dark". If the tracer bullets are hitting the target then you know damned well that the intervening bullets are as well. Inserting code into a system the equivalent of "tracer bullets" gives instant feedback and can produce major changes in the way you approach a project. Rather than designing a "fixed specification" allow the tracer bullets to refine the final "system" and don’t be afraid to refactor the design based upon the "tracer bullet" results. This is a much better method than prototyping in the normal sense of the word as it can give actual factual performance data back immediately. The added benefit is that you will have something to demonstrate very early on in the project - which customers like. Leave these tracer bullets in to indicate the current status of NEW code that needs to be generated or features that need to be added 8. Save all your estimates and be critical of them when making NEW estimates. It is really easy to just say "No problem - I can do that easily". How often have you done this and when revisiting the code the 5 minute job took 5 hours. If you ever make an incorrect estimate, then LEARN from it by finding out WHY it was incorrect. 9. Use the Rubber Duck Technique If possible when trying to pick up a project take time out to explain the project design to another person. Their head should just be nodding like a "rubber duck in a bathtub" regardless of whether they understand or not. HOWEVER, the very fact that you are explaining the design/problem to a 3rd party in detail will allow you to get a full insight into the project. Note that the 3rd person can be inanimate - it is the action of describing simply to someone/something else that makes the technique worthwhile. 10. Use the correct language for the job Need I say it - VFP!!! Dave Crozier -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 269.5.4/768 - Release Date: 19/04/2007 05:32 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 269.5.4/768 - Release Date: 19/04/2007 05:32 _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
