8
$\begingroup$

Computers and programming languages tend to be deterministic and predictable. Yet progress bars seem the opposite, especially if the operation is complex. Even for world class professional products, some progress bars do little to reflect the real progress of an operation. I've seen them go from 10% to 90% in one leap after doing nothing for 4 hours. I've even seen some take steps backwards, suggesting extra unexpected processing has been discovered.

Granted that there may be database operations, network processing and parallel operations but it seems that this could be quantified in some manner and a percentage estimated. After all, there must be a finite amount of instructions executed to complete an operation. Is this simply poor coding, or is there some fundamental reason representing progress is difficult?

||cite|improve this question
$\endgroup$
  • 1
    $\begingroup$ This has nothing to do with computer science. $\endgroup$ – Raphael♦ Nov 12 '16 at 19:29
  • 1
    $\begingroup$ I tried to bring it closer to a scientific framing in my answer. Alas. $\endgroup$ – André Souza Lemos Nov 12 '16 at 19:50
  • $\begingroup$ @Raphael Obviously the 5 readers who posted answers differ to your opinion. It's not about steam locomotion is it? $\endgroup$ – Paul Uszak Nov 13 '16 at 12:06
  • $\begingroup$ No, it's about failings in UI design. Which is offtopic. There may be computer science questions in there, but not in its current form. (Note that your assumption is subtly flawed. While real computers are predictable, strictly speaking, computing a prediction is in general not cheaper than the computation itself. Also, who does the predicting? Applications don't control the machine, so any prediction is predicated on assuming "I'll get as much resources as I've been getting" -- not at all a robust assumption!) $\endgroup$ – Raphael♦ Nov 13 '16 at 13:00
2
$\begingroup$

To add to the more general answers so far I can give a few examples from my field where progress bars don't work and why;

Computer aided design programs - programs that perform thermal analysis or fluid mechanics can be generally terrible with progress bars. They jump forward, backwards, take inconsistence steps and there is almost no use in watching them. This is due to the iterative nature of these types of simulations and the need to find convergence. This is best viewed not by a progress bar but by a iteration v convergence plot.

Complex simulations - I wrote a program that simulates a complex environment with many cross related factors. It was for a fixed timeline so you'd this the progress bar could just be the time right? In my case the simulation too longer with each new time step thereby meaning the progress bar gets slower and slower - not great. I found another metric for how long the average simulation takes based on the number of items in the simulation which was closer to accurate - but not ideal since sometimes the process bar never filled (simulation stopped before) or reach 100% to early (simulation ran longer than expected).

In either case a pure progress complete bar would either be impossible to calculate the maximum for beforehand (case 1) or none linear and hence not much use (case 2)

||cite|improve this answer
$\endgroup$
  • 1
    $\begingroup$ Thank you for your answer. I would like to encourage checking whether the question is on-topic first. $\endgroup$ – Evil Nov 12 '16 at 20:41
  • $\begingroup$ @Evil alas the mobile version of SO hadn't updated that the question was voted as off topic when I wrote this answer. $\endgroup$ – user6916458 Nov 13 '16 at 5:31
3
$\begingroup$

Both. Sometimes it's just difficult to estimate how much time an operation will take, because you don't know ahead how much work needs to be done. Sometimes its simplistic and inaccurate estimates.

Example: I'm downloading four files simultaneously. Someone knows how big each file is, how much has been downloaded, and how many megabytes per second were downloaded for each file. Seem easy to predict how long it will take. However, I know that after one file is downloaded, the others will download faster. Even more after 3 files are downloaded; the last one will download four times faster. Have never seen any progress bar taking this into account.

Example: You are copying a big folder. The progress bar assumes that you copy X megabytes per second, knows how many megabytes there are, and your average speed so far. Problem is, "megabytes per second" is very inaccurate - in practice, it takes x milliseconds per file, plus y milliseconds per megabyte. So lots of small files take much longer than the progress bar anticipates.

The problem is that software developers might care, but their managers don't as long as your computer doesn't crash.

||cite|improve this answer
$\endgroup$
3
$\begingroup$

I think the overarching answer is that it is often too complex (or impossible) to calculate the amount of time it will take.

Sometimes it would just be a matter of crunching more computing time to better estimate the amount of work required (for instance, taking a better analysis of the files to be copied, or applying a more complex calculation to better estimate the number of steps needed to complete a simulation).

Other times it's rather quite indeterminate. When your system is installing a new program, it often has many dependencies to check are installed. And generally it doesn't have an idea of how long each one will take, and what dependencies those may in turn need. You may have all the dependencies installed already and it could take 30 seconds, or you may be lacking dozens and it takes hours. Hard to give a fair ballpark on that, especially when each situation will be unique.

Additionally, other drains on the system may change over time (due to what the user does... or background/scheduled processes).

Sometimes the estimate could be improved if the programmer would put a little more work into them. But then it's another reality that this probably isn't most developers' top concern, compared to furthering the actual productive tasks the application can accomplish.

In the end, right now, I believe it's quite often just a linear estimate -- a look at how many of the required basic tasks has the program completed. So it indeed tends to be a very rough estimate, and you should generally consider it as such going in.

A good analogy might be when you're reading a book.
And you decide you'd like an idea of how long it will take to finish the book...
You could check the page count and get a quick estimate based upon the pace so far.
It might be a bad estimate if you just started reading, because your speed might not be typical yet. But often it'd be a fair rough guess.
Or you could also skim the book, get a rough idea of how many pictures there are and the text spacing. And then have a better idea of what you face.
But it still may be a poor estimate if, for example, the text readability decreases, perhaps transitioning from simple to complex prose. Or the estimate may wind up way wrong because you failed to anticipate another task that will divert your attention.
You could get a great estimate by applying a big chunk of time to carefully analyze what remains in the book page by page, and could likewise improve it by checking your calendar and keeping a list of long-term past reading paces for various books.
But in the end, is the time it takes to do so worth the delay on just getting the book read?

We'd all love better indicators. But as is, we're probably going to have to make due with rough estimates, at least until computers as a whole start getting improved standardized algorithms, and being adept at "intelligently" weighing and anticipating dynamic factors (such as your ways)!

And the progress bar on that is maybe stuck at 5% right now. We'll just have to see how that goes 8-)

||cite|improve this answer
$\endgroup$
  • 1
    $\begingroup$ Thank you for your answer. I would like to encourage checking whether the question is on-topic prior to answer. $\endgroup$ – Evil Nov 12 '16 at 20:36
  • $\begingroup$ Thanks for bothering to answer my question so comprehensively - just ignore Dr. Evil's comment above. $\endgroup$ – Paul Uszak Nov 13 '16 at 21:37
  • 1
    $\begingroup$ Your book analogy is both good and bad. Yes it's like reading a book, but don't forget the book has already been read (by the developers). It should be possible to produce a sort of execution map, milestone statements or critical procedures completed and then feed that back to the user. I'm focusing on commercial software that has already been bench marked for things like performance anyway. If you can bench mark operational performance /resource allocation, it follows that you should be able to bench mark installation performance if the algorithm has been executed before. $\endgroup$ – Paul Uszak Nov 13 '16 at 21:43
1
$\begingroup$

I'd add to the answer of @gnasher729 that this is another hidden consequence of the undecidability of the halting problem.

Setting aside the inherent unpredictability of interactive computations, even those that can be isolated may have an execution time (and "rythm"), whose predictability cannot be approached by a general method.

Sadly, a progress bar is quite often a useless metaphor. What would be the alternatives, you might ask. If the user is aware of what is going on "under the hood", adding some semantic information to the interface can be an option, transitioning to a trace mode-like execution. If not, creating a calm atmosphere that reduces expectations.

Educating the user to understand our limitations is a - long term - third option.

||cite|improve this answer
$\endgroup$
  • 1
    $\begingroup$ I have to take exception to your characterisation of user. A user might be upgrading Oracle Enterprise Business suite for a trading bank which is not like installing Space Invaders. Displaying a progress bar is not there to reduce expectations. but to feedback to the project team how long the trading system will be down. And I'm not sure if this is an example of the halting problem, since a bank might not want to start an upgrade that is not guaranteed to complete... $\endgroup$ – Paul Uszak Nov 12 '16 at 18:23
  • 1
    $\begingroup$ I see no reason why this phenomenon, in general, should ever be attributed to Turing-completeness. Many processes that require progress bars are finite sequences of definitely terminating subprocesses. $\endgroup$ – Rhymoid Nov 12 '16 at 18:23
  • 1
    $\begingroup$ How many times a subprogram will have to run is a non-trivial property of the execution of a program, that affects its estimated time of completion. Rice's theorem shows that these are undecidable problems, by reduction to the halting problem. Concretely, to model the behavior of a program in such detail as to render a progress bar faithful to what is actually going on is usually not feasible, for practical reasons. $\endgroup$ – André Souza Lemos Nov 12 '16 at 18:39
  • $\begingroup$ @PaulUszak How many times have we been hopelessly waiting for programs (upgrades, whatever) to finish? People, banks, aircraft pilots, governments...? $\endgroup$ – André Souza Lemos Nov 12 '16 at 18:42
  • $\begingroup$ @AndréSouzaLemos That's completely besides the point. This is a question about an observation about practice. In practice, the number of times the subprogram will have to run is known within a narrow bound, while the time to spend on it is usually not known beforehand because it depends on I/O. The logic behind progress bars is always crated for a specific applications, and is not generated through program analysis or something else where computability theory would rear its head. $\endgroup$ – Rhymoid Nov 12 '16 at 22:36
1
$\begingroup$

Progress bars are drawn based on the number of subtasks completed rather than on the time elapsed/required for completion.

For example, suppose an operation X has four different sub steps, at the end of each step you increase the progress bar by 25%. If one step take longer to execute, you would likely see the behaviour you described - 1 to 90% in one go and hours for the rest.

The logic behind using number of subtasks as a unit rather than time is that the latter is unpredictable. Even in the case of downloading a file, the connection may drop, hence time cannot be used as a unit. You would rather use the amount of bytes downloaded and not the time required as a progress unit.

||cite|improve this answer
$\endgroup$
  • 1
    $\begingroup$ Thank you for your answer. I would like to encourage checking whether the question is on-topic first. $\endgroup$ – Evil Nov 12 '16 at 20:37

Not the answer you're looking for? Browse other questions tagged or ask your own question.