Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Comment on

( #3333=superdoc: print w/replies, xml ) Need Help??

There is only one, even vaguely accurate, method that I am aware of: Experience.

No other method I've seen comes even close to the guestimate of an experienced, hands-on, developer(read programmer; coder; hacker), but don't be fooled. The experience has to be relevant.

You can have many years, or decades of experience of coding in one language, one OS, or one field of work, and yet be a total noob when it comes any other particular Lang/OS/task.

Longevity can help, especially if it includes a wide range of projects in a leader or manager role, but unless you've done something, or been a part of something really quite similar, there are no guarentees that your experience will be of any help at all.

If your tackling a task fo which you have no experience, and noone with relevant experience to reference, then the best you can do is:

  1. break the task down into lots of very small items of work.
  2. Do your very best to apply realistic estimates (in hours) to each of those items.
  3. Total those estimates and add at least 50% and often 100% to account for:
    • integration;
    • unforeseen addition effort required;
    • spec changes;
    • delays through one source or another:
      • holidays.
      • short weeks.
      • sick leave.
      • company bingos.
      • irrelavant meetings.
  4. Multiply by the "Scotty factor".

    Start with 5 and let them beat you back to 2.

Never under-estimate. Either to secure the work, or to impress the Boss. If you manage to meet your under-estimate through hardwork, overtime (paid or not) or shear brilliance; you've simply made a rod for your own back. It will become the norm and expected.

If the project is new to you and you are going to be held accountable to your estimate: Over estimate the time. Grossly. And then request a reasonable fraction of that time to produce a prototype.

If you're successful, write the prototype as if it will become the real thing but:

  1. Write it top down.
  2. Dummy-up the lower levels as you go.
  3. Go back and fill in as many of them as you can before the deadline.
  4. Stick to the deadline! Doing as little at each level as allows you to move on to the next.

    This includes:

    • Skipping pretty UI's;
    • Omitting error recovery--just die if things are wrong.
    • Ignore edge cases--use carefully selected "middle-of-the-road" data for basic functionality testing (and mid-project demos--if you cannot avoid them).
    • Ignore integrity--replicate a clean dataset for basic testing (& demos).
    • Ignore security--but bear it in mind.

      Add isAuthorised(); checks wherever seems appropriate, but dummy that to sub isAuthorised( return 1; } for getting the prototype going.

    • Go back and expand as many dummied parts as you can in the time.

When you demo the prototype (at the deadline):

  1. Start by demoing clean; middle of the road data.

    Do this quickly and trivially, reserving as much time for the rest of the demo.

  2. Re-run the demo, retaining the dataset from the first run, but demonstrating the flaws. The lack of integrity; security; error recovery etc.

    Place an estimate on the time required to fix each of these things. By this point you will have a much better picture of the overall problem, including what is easy and what is hard, and, what you hadn't thought of in your first estimate.

    With luck and a good tailwind, your prototype will show enough promise to encourage management/customer to accept realistic estimates for it's completion/conversion to production grade code.

Above all, be realistic.

Examine what is said, not who speaks.
"But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
"Think for yourself!" - Abigail        "Time is a poor substitute for thought"--theorbtwo         "Efficiency is intelligent laziness." -David Dunham
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

In reply to Re: Estimating Task Complexity VS Loudmouth by BrowserUk
in thread Estimating Task Complexity VS Loudmouth by Eyck

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?

    What's my password?
    Create A New User
    [haukex]: Discipulus: which one do you mean?

    How do I use this? | Other CB clients
    Other Users?
    Others lurking in the Monastery: (8)
    As of 2018-06-22 08:09 GMT
    Find Nodes?
      Voting Booth?
      Should cpanminus be part of the standard Perl release?

      Results (122 votes). Check out past polls.