Greetings all -- I have been active in all phases of computing in all environments -- analysis and design, programming, management, education, commercial, industrial, military -- for over 50 years.
Tomasz described techniques used in the "olden" days, and those techniques are still among the best. I recommend beginning with a short search through easily accessible materials. If the solutions shows up, fine. If not, I define the problem as directly as I can, then write a separate program to test exactly that problem. I want two versions of the program, both as simple as possible -- one that works and one that fails. This allows me to focus on the difference between them, which is usually the part that is failing. If the problem is not immediately apparent, I look at it for several hours, explain it to my toaster, wash the car, take a nap, etc. When I come back to it, it is almost always one of those "hit myself in the forehead" moments. There are several other methods for estimating time and effort. For a project that is underway, you can extrapolate. Take the proportion complete and the time expended. Extrapolate to give an estimate of how long it will take to complete 90% of the project. The remaining portion will take the other 90% of the time. Thanks for listening, Howard On Wed, Sep 30, 2009 at 11:38 AM, Mike <[email protected]> wrote: > > > Unfortunately, there is no science to scheduling. Years ago I manged a > group of senior developers, reporting progress regularly to the president of > the company. I ended up spending about 30% of my time fudging the schedule > just keep it looking like things were progressing! > > Two quick tips that might prove useful though: > > 1. Learn to use advanced search features of your favorite search engine. > For example, simply appending site:amibroker.com to any AFL related search > will help to drill down to what you are after. > > 2. Structure your code so as to be able to reuse as much as possible in a > different scenario. For example, if you find yourself writing utility code > within a chart, break it out into a function and put it into a separate file > for #include_once usage. > > Mike > > --- In [email protected] <amibroker%40yahoogroups.com>, "Jeff" > <jeffro...@...> wrote: > > > > I am not a native programmer, but lately it seems that's all I do. The > biggest problem I have is prioritizing projects when I don't know how to > estimate how long it will take me to write a program. Yesterday I worked on > one which I thought should only take me an hour to finish. Six hours later, > my brain is fried, I'm cursing at the dog and I still can't get the program > to work right. I finally figured out I didn't capitalize one of my objects > (using Rmath). > > > > Another example would be aimlessly searching the Amibroker guide, > Knowledge base, User's KB, etc. for a reference I can't find anywhere. So, > then I post a question in this forum, it doesn't get answered so then I have > to figure out another way around my first code,etc.etc. > > > > I'm not complaining about not getting answers on the forum or not finding > answers in the user's guide-- I have no control over these things. I am > wondering if anybody else can relate to my experiences and how you dealt > with the problem. Specifically how were you able to better estimate how long > it would take you to finish a program. > > > > Thanks! > > > > >
