Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

The ninety-ninety rule

by little_mistress (Monk)
on Apr 15, 2000 at 03:47 UTC ( #7679=perlmeditation: print w/replies, xml ) Need Help??

The first 90% of a project takes the first 90% of the time.
The last 10% of a project takes the other 90% of the time.
Why?

ponder and respond.

2004-10-18 Edit by Arunbear: Changed title from 'Time'

Replies are listed 'Best First'.
RE: The ninety-ninety rule
by chromatic (Archbishop) on Apr 15, 2000 at 09:31 UTC
    The first 90% of any of my projects consists of getting something -- anything -- working. As I usually underrate the complexity of the problem and overrate my ambition to solve it, time drags on.

    By the point of 90% completion, I move into a polishing sort of mode, where I remove the awkward bits and refine sections, moving pieces back and forth like some linguistic crane operator. When I can no longer stand to shave off more, I know it is as finished as it will be.

RE: The ninety-ninety rule
by frankus (Priest) on Apr 25, 2000 at 20:15 UTC
    Is it because after 90% is done the client changes his mind and alters the spec, or the project managers panic and throw lots of green coders at the problem; meaning you spend 90% of your time bringing them up to speed in the project. These have been my experiences, sorry that they're so plain.
Re: The ninety-ninety rule
by apotheon (Deacon) on Oct 16, 2004 at 22:20 UTC
    Time dilation. We're talking about general relativity here, and the fact that as you approach c you experience time dilation effects. By the same token, if you throw something at a black hole, when it hits the event horizon it subjectively seems to slow to almost a complete stop. That's just time dilation at work.

    - apotheon

    CopyWrite Chad Perrin
RE: The ninety-ninety rule
by infinityandbeyond (Sexton) on Apr 20, 2000 at 19:44 UTC
    Feature creep. The customer is never satisfied with his/her original specifications, and likes to change them. And waits until the very end of the project to tell you that he/she has changed their mind.
      I always thought that was just part of the development cycle ;-). You know, plan, develop, test, develop, test, develop, test . . . .
      Simplicus
RE: The ninety-ninety rule
by turnstep (Parson) on Apr 15, 2000 at 21:29 UTC
    Because the devil is in the details.
RE: The ninety-ninety rule
by ChuckularOne (Parson) on Apr 20, 2000 at 20:51 UTC
    It is a time compression thing.
    The closer you get to "GO" the longer each second feels
    In one hour, one hour before something must go live, you can acomplish 3 hours worth of work.

    Your Humble Servant,
    -Chuck
RE: The ninety-ninety rule
by toadi (Chaplain) on Apr 26, 2000 at 18:02 UTC
    I'm a Webmaster,
    Most of the time the customer doesn't know what he wants.
    They refer to existing web-sites and say I want it like that.
    Every nice and original touch to improve bad design flaw's are rejectd by the client.
    I've got the feeling everybody thinks the 'microsoft way'.

    -- My opinions may have changed, but not the fact that I am right
Re: The ninety-ninety rule
by logan (Curate) on Oct 17, 2004 at 00:28 UTC
    There's more. As I work through a project and it takes shape, I see possibilities. Case in point: I was working on a tool to monitor 5 simultanious video installations. The tool had to be completly modular and run unattended. Much of the work came with developing the syntax of the config file. Once that was done, I saw how I could use my existing logic and syntax to do siultaneous testing of other features. Implementing this slows down development.

    As the project approaches completion, there's cleanup and endgame tasks to do: write documentation, standardize and format logging and debug messages, et cetera.

    Finally, there's the time-compression phenomenon. Managers never feel useful unless they've recently given an order. As the project moves on more time has passed since the original order. The manager, unable to see work being done on a long-term project, begins to feel lonely and insecure, and must issue a new order to feel important. The developer is then given a new task to do "in their spare time" or "just real quick". This slows down development of the original project. To combat this phenonenon, I recommend breaking random things around the office. It'll give your manager something to do so they'll feel special and leave you alone to do your job.

    -Logan
    "What do I want? I'm an American. I want more."

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://7679]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (2)
As of 2021-10-28 21:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My first memorable Perl project was:







    Results (96 votes). Check out past polls.

    Notices?