If you’ve spent any time at all on Internet message boards, you’ve probably seen the same question asked over and over again. On computer message boards, a common question is “Why do the progress bars (meters) in Windows suck so much?” You’ve probably dealt with this yourself: you want to move a file from one hard drive to another on your computer, so you do the drag and drop thing, and Windows’ progress meter appears… “2 minutes remaining”. It then inexplicably jumps up to “38 minutes remaining” for a minute or two, then drops back down to “45 seconds remaining” before jumping back up to “1 minute remaining”. A similar thing sometimes happens when you’re installing software: the progress meter will slowly move up to, say, “38% complete”, and then stay there for a couple of minutes before suddenly jumping up to “75% complete”.
What’s the deal? Well, the snarky answer is that “your computer can’t predict the future”. The longer answer is the same, only slightly more involved.
Let’s say that you have a GPS system in your car. You’re sitting in downtown Charlotte, NC and want to drive to an address in downtown Atlanta, GA. You enter the address into the GPS unit, which immediately gives you an estimated drive time of 3 hours and 25 minutes (which is based the current distance you want to drive divided by 55mph). So you start driving to the address, and the estimated drive time slowly starts ticking down… “3 hours, 15 minutes remaining… 3 hours, 5 minutes remaining… 2 hours, 55 minutes remaining”. As luck would have it, there’s a massive wreck just outside of Greenville, SC. You’re stuck in bumper-to-bumper traffic and are doing around 2mph. Suddenly the estimated drive time jumps up to “16 hours, 47 minutes remaining”. As you creep along, the drive time keeps getting longer: “18 hours, 2 minutes”. You finally clear the wreck, and you figure that all the local cops are busy dealing with the accident… so you floor the gas pedal. Once you hit 125mph, the estimated drive time plummets to “45 minutes remaining”. Your road rage subsides after a few minutes, so you lay off the gas and settle in at a more reasonable 70mph. The estimated drive time is now back to a more normal “1 hour, 25 minutes”.
And that’s pretty much what Windows has to deal with when estimating the time it will take to do a task. When you begin the file copy, Windows will make a “best guess” at how long the transfer will take, much like the GPS when you first put in the destination address. But then any number of things can take resources away from Windows and slow the file copy down: perhaps your antivirus software wants to scan a file… maybe Windows needs to page some data from RAM to your hard drive… maybe you get tired of waiting and open a web browser or your email program. And if you’re copying data from one computer to another, any of those things can slow down the destination computer, too.
Although the same principle is in effect during software installs, it’s a little more complex overall. Imagine that you have a list of things you need to do tomorrow:
1) Get up
2) Take a shower
3) Get dressed
4) Take the dog for a walk
5) Run errands
6) Mop floor
7) Dust furniture
To keep this analogy accurate, we’ll have to pretend that you must follow the list in order, and that you must be completely done with one task before you can start another.
Let’s say that you’re really pressed for time, and you decide to hire some folks to help you with #5: running errands. You actually have a “sublist” for #5 which includes “go to post office”, “pick up dry cleaning” and “go to grocery store”. So you hire three people to do each errand for you. You have a pretty good idea that the guy going to the grocery store will take the longest, but you can’t be sure of that. Maybe the guy picking up the dry cleaning will get stuck in traffic, or maybe the line is really long at the post office. In any case, you can’t move forward with your list until they’re all back at your house. And one by one, they come back. And once they’re there, you can continue with tasks 6 and 7.
If we break down your task list into how much time each task would take, you’d see that task 1, 2, 3 and 4 go by pretty quickly. So your “progress bar” for these tasks would quickly reach the “25% completed” mark. But task 5 will take a lot of time, so while you’re sitting there waiting for the guys to come back from the errands, your progress bar will sit at “25% completed”, but will jump to “75% completed” when they return. At that point, you can begin tasks 6 and 7, which will push you to “100% completed”. Software installs work the same way. How they work is a little too complex for this post, but hopefully you’ve gotten an idea of why it happens.
Incidentally, this isn’t just a Windows problem. I said that that this happens because your computer can’t predict the future, and not because your operating system can’t predict the future. Mac and Linux have this same problem too, although you’re more likely to see it on Windows. Why? Because it’s such a daunting problem for programmers, many have simply given up trying to write accurate progress bars. Instead most modern progress bars exist simply so you’ll know that the computer is actually doing stuff and not locked up.
I recently did a file copy of 15 G from my PC to a backup drive to a mac.
The mac predicted the transfer time within a minute, never wavering from its initial (correct) estimate of 15 minutes. My PC reported everything from a few seconds to 48 minutes for the same transfer.
My GPS uses a constant speed estimate for my travel. So if I get delayed by a traffic jam for two hours, its estimate is off by at most two hours. But then quickly becomes accurate again once I get moving.
Clearly instantaneous rate methods are awful and as you’ve seen can produce estimates off by orders of magnitudes. Either constant rate or smoothing over recent history are much much better.
The Windows are estimates are bad because the algorithm is bad. This may be due to laziness or ineptitude, but not because the problem can’t be solved better.
Microsoft doesn’t care