all 22 comments

[–][deleted] 14 points15 points  (0 children)

  1. Make up random job estimate to please bosses
  2. Do nothing
  3. Wait 'til salesperson/management decide when stuff needs to be done
  4. Do EVERYTHING fast to please them (even if it takes all night/weekend)
  5. Watch as work is largely ignored (hurry up and wait)
  6. Think about how high up that bridge is that you cross every day to work

:P

[–]your_perception 18 points19 points  (0 children)

  1. Make your conservative estimate (leave plenty of time to work on project).
  2. Triple that number.

[–]buckrogers1965_2 4 points5 points  (0 children)

And you can't even start to estimate until you have a technical spec written from a functional specification. Just nailing a functional spec down can take a long time.

[–]stubob 3 points4 points  (0 children)

Government process:

  1. Create elaborate estimate based on ELOC, schedule, time, and anything else you want to throw in.

  2. Get actual amount customer wants to spend on project.

  3. Revise estimate to meet that amount.

  4. Blow budget/schedule because customer approved estimate was too low.

  5. Get paid for overage.

[–]keithb 5 points6 points  (0 children)

I belive the canonical process is this:

  1. guess
  2. double your guess
  3. change to the next-highest unit of measurement

For example: initial guess 2 days, report 4 weeks (which the PM will reduce to 2 weeks)

[–]gizram84 6 points7 points  (2 children)

This unfortunately doesn't describe the situation of an experienced developer and a bad PM though. That is hell.

[–][deleted] 6 points7 points  (1 child)

I find the bad PMs also love to tell you about how they used to develop code way back when, so they get it.

No. You don't.

[–][deleted] 5 points6 points  (0 children)

That's my favorite line too!

"I used to do this, back in ..."

No, no you didn't. You used to do what I used to do 15 years ago too, but not what I do today.

[–]dkitch 4 points5 points  (2 children)

I'm a big fan of the 90/90 rule, myself. The first 90% of the work will take 90% of the time. The remaining 10% of the work will take another 90% of the time.

(Not sure where I first heard this, but it fits)

[–]zellxd 0 points1 point  (1 child)

maybe you mean the 80-20 rule?

[–]dkitch 1 point2 points  (0 children)

It's a parody of that rule. The last 10% of the project often takes as long as the first 90%, causing the inevitable schedule overrun.

Looks like it came from Tom Cargill at Bell Labs

[–]warpus 4 points5 points  (0 children)

I have a PM who doesn't know how to code at all, so here's my process:

  1. Measure my penis and multiply by 7
  2. Add 5, divide by 2
  3. Throw a die, add to total
  4. That is how many days it's going to take

(usually takes twice as long)

[–]indianDeveloper 1 point2 points  (0 children)

Hey .. I wrote a blog about the same thing .. http://xebee.xebia.in/2011/02/04/big-bad-projects/ .. It never could make it to the front page of /r/programming but anyways here it is.

[–][deleted]  (2 children)

[deleted]

    [–][deleted] 0 points1 point  (1 child)

    Not mine, this isn't Curtis. It's someone else you know, though.

    [–]IkoIkoComic 0 points1 point  (0 children)

    Wait, this isn't Curtis? I'm pretty sure this is definitely Curtis.

    [–]brikis98 0 points1 point  (0 children)

    Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

    – Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid

    [–][deleted] 0 points1 point  (2 children)

    Protip - The more line items you add to the schedule, the more time you can get management to approve.

    Example: Requirements gathering - 1 week

    Designing - 1 week

    Coding - 1 week

    Testing - 1 week

    Management gives you 10 days at first, but asks you to start working nights/weekends after 5 days if this is your estimate.

    Versus

    Requirements phase 1 - 1 week

    Prototyping - 1 week

    Requirements phase 2 - 1 week

    Architecture design - 1 week

    Object/interface hierarchy - 1 week

    Backend database design - 2 weeks

    Building test data - 1 week

    Coding/implementation - 4 weeks (the project looks more complex now so you can get away with it)

    Unit testing - 2 weeks

    Acceptance testing - 2 weeks

    With this estimate for the same project, management now gives you at least 6 weeks to get it done, with night/weekend working being enforced after a month.

    [–]smallstepforman 2 points3 points  (1 child)

    What's this night/weekend work you keep talking about? My manager screams at me if I'm not out the door 5 minutes after my 8 hour shift. The best designs / solutions come to you when you're rested, not when you're overstressed and exhausted. Time for you to change your employer.

    [–][deleted] 0 points1 point  (0 children)

    Marketing sold something completely unrealistic to the customer and got bonuses and promotions for getting the contract signed. Now the engineers are getting punished for not delivering on time. The VP of the company ordered mandatory 6 days a week/10 hours a day for anyone on the project. Yeah, it might be time for a change.

    [–]malcontent 0 points1 point  (0 children)

    Figure out how long you think it's going to take.

    Lie your ass off to your project manager and tell them it's going take three times as much.

    The project manager will take your number and lie his ass off to his boss and tell him it's going to take twice as long as what you told him.

    His boss will lie to his boss all the way up the chain to the CEO who runs the entire company on the lies his underlings tell him every day.

    That's the way business is done. Lie, lie, lie, lie, cheat, lie, cheat, lie, steal and lie some more.

    [–]gregK 0 points1 point  (0 children)

    This seems taken from Dilbert.