I've noticed that most of the time, progress bars are pretty much useless.
A progress bar is supposed to give the user an idea of what percentage of a task is completed, and how much remains. It's also supposed to be a kind of visual indication as to how much time remains until the task is complete.
The problem is, they're never valid unless they move at a constant speed.
For example, say you are compiling a large program (and your compiler has a progress bar.) The progress bar is chugging along at varying speeds, and then it stops at 84% while it compiles a particularly complex segment of code. After 10 minutes, it continues on from 84%, and finishes compiling.
Divide the task into 5% increments. Because the progress from 20% to 25% doesn't necessarily take the same amount of time as the progress from 60% to 65%, that makes progress bars horribly inaccurate, and useless as an indicator of completion.
In response to this argument, people will say "Well, they can still give you an idea of how much of the task is finished." This is incorrect. Let's assume we're computing a task that takes exactly two hours. By this logic, we would assume that a progress bar would hit 50% after an hour. In our example, however, it takes one hour to complete 65%, and the remaining hour is spent computing the last 35%.
Now since there is a variation in the amount of computation done each hour, the progress bar is totally inaccurate. If the job takes two hours, the progress bar should be at 50% after one hour. In our example, however, the progres bar stated the last 35% of the project was more intensive than the first 65%. This doesn't make sense, as any task requires 100% for completion.
Therefore, there is a 15% margin of error in our example. To have an accurate progress bar, it absolutely must move at a constant rate.
File download transfer bars are exempt from this argument, as they do calculate percentage based on amount downloaded versus total size. I have noticed that the ETA on a download is almost never accurate, however.