# predicting the length of tasks

Page 1 of 1

## 2 Replies - 411 Views - Last Post: 05 June 2018 - 01:51 AM

### #1 bobsmith76

• D.I.C Regular

Reputation: 11
• Posts: 363
• Joined: 14-February 17

# predicting the length of tasks

Posted 04 June 2018 - 11:17 PM

I started keeping track of how long it takes for me to do each task. Before I start a task I estimate how long I think it will take. I try to have a very precise goal in mind which will signify the completion of the task but this is not always the case. So I think for the task which I thought would take 20 hours but ended up taking 16.9 I think my original goal was to get an algorithm to pass a 1000 tests, but I instead revised it to just one test. The one task which took 5 hours but ended up taking 148, well, I think that was my worse ever task, so that sort of thing does not happen all that often. I have a few tasks where I thought they would take 10 hours or 5 hours and ended up taking 1 hour. That was mostly because I had to use some functions which had not been used in a very long time and I thought they would require a lot of debugging but it turns out that they did not.

In the following chart the numbers on the left are the estimated number of hours I thought it would take to do the job and the numbers on the right are the actual amount of time it took.

https://ibb.co/h6pVco

Is This A Good Question/Topic? 0

## Replies To: predicting the length of tasks

### #2 andrewsw

• quantum multiprover

Reputation: 6776
• Posts: 27,942
• Joined: 12-December 12

## Re: predicting the length of tasks

Posted 05 June 2018 - 01:27 AM

The more you can break down a task/project into distinct steps the closer estimates will be.

It also depends on your definition of done. Something that looks like it works can take little time; code that is clean, maintainable and thoroughly tested will take a lot longer.

Personally, there isn't much time or project management going on where I am. I am finding that I follow the Pareto principle (roughly), in that I can get 80% of the way to completion in what eventually proves to be 20% of the time, with 80% of the time spent wrestling with the 20% of the niggling little bits. The scaffolding looks good and stable, but there are lots of loose screws around?!

Quote

It was also discovered that in general the 80% of a certain piece of software can be written in 20% of the total allocated time. Conversely, the hardest 20% of the code takes 80% of the time.

wikipedia

### #3 bobsmith76

• D.I.C Regular

Reputation: 11
• Posts: 363
• Joined: 14-February 17

## Re: predicting the length of tasks

Posted 05 June 2018 - 01:51 AM

Thanks for the tip on the Pareto principle. I always thought it was 85/15. I had heard of that law before, I thought it was just called the Power Law but now I'm glad to see that it has a name. I also think I might start trying to establish an estimate one hour into the task. As far as the definition of 'done' I usually set out a distinct point in the code that I want to be able to progress towards before I consider the task done.