I remember one of our developers saying how hard it is to make a progress bar work the way you think it should. Everytime I see one struggle to get to 35% and then suddenly say "DONE!" I think of him.
Progress bars are indeed hard.
A very simple example is you have one job with 10 tasks that you must delegate to others, sequentially. You have no idea how long those tasks will take. How do you report progress?
A easy way is to report 10% done for each task. What if the first nine of those tasks take one second but the last one takes one hour? You’ll zip through the first 90% and wait a long time for that last 100% report.
The obvious next step is to have the person in charge of the one-hour task report how many sub-tasks they have - let’s say 10 subtasks - and report back when each sub-task is done. Now, at the top level, you know there are 20 total tasks+subtasks and you can report 5% per task/subtask completed.
Out of those 10 subtasks, let’s say the first nine take one minute and the last one takes 51 minutes. Now you zip through 95% and wait a long time for that last 5%.
This example is ”simple” compared to actual software development. The number of levels of delegation is very large, the number of tasks performed at each level is constantly changing, and the tasks themselves are also constantly changing. It takes a lot of profiling on stable code to find some measurement that correlates to user time.
Unless a smooth progress bar is a necessary product feature, the effort involved isn’t worth it.
territory.
