Why are developers expected to estimate tasks at all?

General Developer Forum In The News
1

Why are developers expected to estimate tasks at all?.
This management tendency is the worst part of being a developer. Software development is not carpentry. Almost everything a developer writes is unique, they have never built that particular thing b…

Read in full here:

This thread was posted by one of our members via one of our news source trackers.

2

Corresponding tweet for this thread:

Share link for this tweet.

3

I am really bad at estimating tasks. I work hard, but I like to do it at my own pace. So I usually add a day or two to my estimates. :slight_smile:

1 Like
4

Estimating every single task is a bad practice from my experience. Especially when working on new things (like first time using 3rd-party API) you have no idea how long it would take. Not even mentioning that you may get stuck on simplest typo/bug and circle around for a long time. Not everyone knows that best solution for it is toilet. :toilet:

Anyway what I found reasonable is preparing a dashboard of tasks that needs to be done, declare deadlines (like MVP or release) and split them on 1-2 week iteration. For each iteration assign issues in following order:

  1. Bug fix - with good code most of them are “5 min” tasks, those always have priorities
  2. Features (i.e. big tasks) starting with highest priority
  3. Enhancements of features - usually at most medium tasks that takes the rest of the time, as above you start with those with highest priority
  4. Tiny changes - similar to bug fix, but those (for example changing color) usually have lowest priority

So instead of saying:

I think that I can finish this task in x hours

you say:

In next iteration I would be able to fix all known bug fixes, introduce (…) new features, enhance (…) existing features and meanwhile I would close (…) small tasks as I remember what and where I need to change.

With this:

  1. You agree that you do something regardless if it would take “5 or 15 min.” more, because you get stuck on something.
  2. Someone is willing to pay for said iteration and this person is not interested in tracking your time
  3. You would not receive questions like “Why this simple task took you so long?”

If you cannot agree on amount of work for such iteration either someone tries to force too much things to it or you need to improve your skills. All the rest is in under your control. Since you declare that some group of tasks should take up to 40 hours if you really worry about your time at work you would start tracking work time yourself without worries that you would need to present results to anyone.

With such agreement especially when working remotely you may easily go for flexible work hours (except chat and meetings of course) as someone expects some work on next Monday, so no matter if you work in Monday or you feel bad and you continue on Saturday.

It’s not even all you may win in such case. If you agree for next 2-3 iterations you can do “overtime” and like me finish 3 iterations in 2 weeks. This way you would receive extra money sooner and possibly you can work on next iteration in standard hours.

The other thing is mental attitude. Regardless of salary because of “small steps” technique you would receive money faster, so it would be much easier to motivate yourself in every next “Monday”.

1 Like
5

This looks like a good read on software estimation: Software Estimation Without Guessing: Effective Planning in an Imperfect World by George Dinwiddie

1 Like