Here is my recipe to tackle this problem: 1: break down the problem into small items - like Howard explained. Use a Todo-list tool like this one: http://www.abstractspoon.com/ , to keep yourself sane and focused. 3: prioritize the small chunks, and execute them. Record the time it takes to code up an item. 4: assemble the chunks 5: review and learn how long it took to execute the different subtasks. This will be your best guess with a fudge factor for your next similar project. And most importantly STAY FOCUSED.
Zsolt --- In [email protected], Howard B <howardba...@...> wrote: > > 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 <sfclimb...@...> 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" > > <jeffro861@> 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! > > > > > > > > > >
