|
PureBytes Links
Trading Reference Links
|
"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." Truer words were never spoken.
As an electronics hardware engineer, I learned to think in terms of
"the first 90% and the second 90%".
On a more practical level, try this:
1. Write down a list of sub projects for your main project, with
estimated time and a place for actual time. Leave room for adding
comments, now and later. I start with paper. Add up all your
estimated times and multiply by a fudge factor.
2. Immediately or as soon as you START to get into ANY trouble (actual
> estimated time), move it all over to a spread sheet. As soon as
your project is on a spread sheet, you can then:
a) expand your comments
b) break your sub-projects down to sub-sub-projects with there own
estimated and actual times.
c) add additional time to original estimates in NEW columns. Do NOT
remove the original estimates. They will help you refine your personal
fudge factor in the future.
BTW, the first time you do this it will seem like a waste of your
'productive' time. Do it anyway.
BTW2, if you work for a boss who would rather be optimistic than
realistic, it might be better to not let him/her see what you are doing
(assuming you want to keep your job until the economy picks up).
BTW3, avoid "feature creep", and project changes. If you can't avoid
them (your boss insists), definitely add them to your spreadsheet and
note its impact on all the other 'unrelated' sub-projects.
BTW4, substitute 'customer' for 'boss' above as appropriate. But be
much more wary of an optimistic customer than an optimistic boss. The
boss has to pay you, even if he fires you. The earlier an optimistic
customer sees the effect of his changes, the better, for both him/her,
you, and your wallet.
-- Keith
Howard B 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 <sfclimbers@xxxxxxcom>
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
> 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!
>
__._,_.___
**** IMPORTANT PLEASE READ ****
This group is for the discussion between users only.
This is *NOT* technical support channel.
TO GET TECHNICAL SUPPORT send an e-mail directly to
SUPPORT {at} amibroker.com
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
![]()
__,_._,___
|
|