|
PureBytes Links
Trading Reference Links
|
You guys are awesome! I really appreciate the well thought out, practical responses. I have ofter thought that ready access to unlimited information has the unwanted side effect of becoming "trapped in the box" (as much as I hate that term)-- I know what you mean. I have just gotten to the point where I'm forcing my self to me as modular as possible. I should probably also mention that I am as scatter brained as they come. My software that i use for planning is overkill and probably more sophisticated than some of my trading systems. I've kind of fallen off this whole organization kick that was on, mainly because of getting frustrated with not "getting things done", at least not as quickly as I had hoped. I will definitely being use these suggestions.
Thanks again,
Jeff
--- In amibroker@xxxxxxxxxxxxxxx, Keith McCombs <kmccombs@xxx> wrote:
>
> "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@xxx
> > <mailto:sfclimbers@...>> 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
> > <http://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 amibroker@xxxxxxxxxxxxxxx
> > <mailto: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!
> > >
> >
> >
> >
>
------------------------------------
**** 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/
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:amibroker-digest@xxxxxxxxxxxxxxx
mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|