4 ms·

I think that the longer I've worked as a developer, the more inclined I am to be a pessimist. Sometimes projects look so freaking easy but then you realize you'

I think that the longer I've worked as a developer, the more inclined I am to be a pessimist. Sometimes projects look so freaking easy but then you realize you've just spent 3 weeks working on one feature out of a dozen and you're about to hit your first deadline. I definitely do the "manager doubling" when it comes to estimates. If I think it'll take a month, I estimate 2 months to my boss. If I have to report several levels up, I multiply by 2 for every level.

pimlottc 11y ago
What's frightening is the variability of daily productivity. Some days everything comes out the first time, you're using the right framework and you finish 20% of the project with 10 lines of code. Other days, you lose hours chasing down a bug from a single typo, or debugging an obscure corner case incompatibility between two libraries. And there's no sure way of telling what kind of day you'll get next.
- lifeisstillgood 11y ago
  This is almost correct - I think if you work all the time to keep it simple, the days of badness are fewer
  - bruceboughton 11y ago
    Then the first derivative comes into play: some days you manage to keep it simple, other days you overcomplicate things. And there's no sure way of telling what kind of day you'll get next. This tends to affect future work rather than the current sprint.
  - collyw 11y ago
    They can still exist. Its not always in your own code.
jgroszko 11y ago
> I definitely do the "manager doubling" when it comes to estimates. If I think it'll take a month, I estimate 2 months to my boss. If I have to report several levels up, I multiply by 2 for every level. Hah, I like this. Every level up that sees it is also a potential for more scope creep, as each person will have their own vision of what's being produced. One of my favorite estimating guidelines from a mentor was that development tasks are either 2, 4, or 8 hours. If it's more than 8 hours it can be broken up into smaller tasks.
- nstart 11y ago
  The most common time the 8 hours policy breaks down (insert rage face here) is when going bug hunting on non straight forward bugs. I just got out of a 5 day bug hunt where the fix was literally changing a 10 to 40 (so, 1 character change). The debugging process to realise this was painstaking elimination of possible causes. I eventually stumbled on the root cause by mistake when I out of frustration just switched an unrelated boolean flag to see if I could get a laugh out of what happened next. These tasks can really screw up an entire dead line. I have a policy on those which is two steps: 1) Daily report in the morning SCRUM style of what was tried, and what's going to be tried next. 2) After a full working week, reassess everything and try and understand where you are going with this. Rinse and repeat. Basically the estimate is set at 5 full working days whenever you work on an obscure problem. But it's not a hard deadline. It's just a hope that it'll work out by then and a mild mental aid of giving something to work towards.
  - dagw 11y ago
    It takes 8 hours to implement the feature. It takes a lot longer to make it actually work.

pimlottc 11y ago

What's frightening is the variability of daily productivity. Some days everything comes out the first time, you're using the right framework and you finish 20% of the project with 10 lines of code. Other days, you lose hours chasing down a bug from a single typo, or debugging an obscure corner case incompatibility between two libraries. And there's no sure way of telling what kind of day you'll get next.

lifeisstillgood 11y ago
This is almost correct - I think if you work all the time to keep it simple, the days of badness are fewer
- bruceboughton 11y ago
  Then the first derivative comes into play: some days you manage to keep it simple, other days you overcomplicate things. And there's no sure way of telling what kind of day you'll get next. This tends to affect future work rather than the current sprint.
- collyw 11y ago
  They can still exist. Its not always in your own code.

jgroszko 11y ago

> I definitely do the "manager doubling" when it comes to estimates. If I think it'll take a month, I estimate 2 months to my boss. If I have to report several levels up, I multiply by 2 for every level. Hah, I like this. Every level up that sees it is also a potential for more scope creep, as each person will have their own vision of what's being produced. One of my favorite estimating guidelines from a mentor was that development tasks are either 2, 4, or 8 hours. If it's more than 8 hours it can be broken up into smaller tasks.

nstart 11y ago
The most common time the 8 hours policy breaks down (insert rage face here) is when going bug hunting on non straight forward bugs. I just got out of a 5 day bug hunt where the fix was literally changing a 10 to 40 (so, 1 character change). The debugging process to realise this was painstaking elimination of possible causes. I eventually stumbled on the root cause by mistake when I out of frustration just switched an unrelated boolean flag to see if I could get a laugh out of what happened next. These tasks can really screw up an entire dead line. I have a policy on those which is two steps: 1) Daily report in the morning SCRUM style of what was tried, and what's going to be tried next. 2) After a full working week, reassess everything and try and understand where you are going with this. Rinse and repeat. Basically the estimate is set at 5 full working days whenever you work on an obscure problem. But it's not a hard deadline. It's just a hope that it'll work out by then and a mild mental aid of giving something to work towards.
- dagw 11y ago
  It takes 8 hours to implement the feature. It takes a lot longer to make it actually work.