There is deterministic and then there is deterministic. At the developer level, which almost always means some high level language, there is very little that is deterministic. You don't have the ability to see what other processes are doing at the exact moment you do anything (fundamental limitation due to relatively electrons can only move so fast a query and response won't ever be syncronous from any two points in space (in all reference frames)). But even say that you could know exactly what is going on right now there is a duration to your activity and at any point between start and finish the system state can change.

Okay that is enough for hardware (at least at this level). Next up compiler and machine instruction set: just because you right a set of lines in a particular order in a high level language doesn't mean that your instructions will be run in that order either the compiler or the CPU could reorder/combine operations without you knowing. This might be a run time thing too (say the CPU only does predictive branching when the pipeline has additional items in it for example). Mah either way the developer or the user can't be reasonably expected to know what is going on. Multitasking also means things might not be where they were when you got interrupted by another thread meaning you might have to wait on several loads of the same item as your stuff keeps getting knocked out of registers and higher level memory.

Mostly agree other than the labelling being a waste. I'd caveat that with "it depends". Can the user still interact with your program and get useful work done (example syncing an iPod doesn't mean you can't listen to music at the same time) if so then screen real estate is important and you should get out of the way as much as possible. Versus installing upgrading type behaviour (or a program who's sole purpose at the moment is to do what it currently is doing like file transfer) in that case feel free to take over the whole window and give really fine grained info to the user if it will help. Usually the tradeoff here just becomes a matter of avoiding clutter rather than really saving screen real estate. Programs that list every file they copy quickly take over the whole visible window and then you end up scrolling up and down if you care, or it scrolls so fast through the console that it might as well not have been shown at all.

I kind of liked the old XP installer: 30min remaining. Don't even try to give an accurate time like you say soon, now, and a long time should be good enough. Heck if you reasonably suspect that your process is going to take > 10 minutes change the mouse pointer to a cup of coffee and the status message to "Processing, you're going to be here a while". It's the not knowing when it will speed up and suddenly finish that leaves the user sitting around staring at the screen. Tell them it will take a long time and subtly hint that they find something else to do and they might not even notice.

A key part of the central limit theorem is that the variables are independent. The time for one disk access and the next clearly isn't for example. Also the central limit theorem doesn't say anything about how big the resulting standard deviation would be. Most performance metrics are hugely right skewed. A disk access takes a millisecond if it is small and in the disk cache already, but if large and not in cache it can take minutes. So you can end up in situations where the whole process is running fine and then one step takes a 1000 times longer than the rest. Developers have no way of knowing how fast your CPU is versus your disk, how fast an internet package you have, how good your CPU is with floating point etc. so even if they tested and picked the mean of the CLT distribution the individual steps of the progress bar might be meaningless because they didn't count on you still using dial up for step 4, having the HDD disk on the far side when setup 2 started etc.

The list/status bar solution is nice for another reason: if your program does hang your users know where in the process it happened. You get more useful feedback from the users, sometimes they might be able to troubleshoot it themselves (oh it is dying when connecting to my fileserver, perhaps I"m not connected to the network). Heck it is useful for course grained optimization you see the logical steps that take the most time and can drill down into speeding them up as much as possible.

This is why if it is something the user will understand I like to use a status bar instead. Much nicer to see things moving through a workflow than trying to guess how long the db load vs analysis will take and display the progress bar correctly which will change as the data grows, complexity of the problem, computer the user is on etc. Progress not timing, we should just completely remove the complete from the visual just have a numerical counter, if it is increasing things are still working.

Well we do this in the real world too though say asking the mechanic when you can get your car back. Just asking wastes resources and means the answer is "later than it would have been before you interrupted". But even with a rough estimate is usually pretty good (except when it isn't and then it really isn't like installing apps and seeing 10min go to 2hrs) and can adapt to changing data. I think the problem is expectations: we want exact answers which is understandable if you are waiting for something (I work with radiation simulation software you can be waiting for 20min for a result if you knew exactly when you could leave instead you watch the progress bar) but exact answers are not inherent in either the hardware or the problem space that we are working.

If you can afford that for a phone you'll probably want to replace next year you can afford a couple Indian developers to make whatever apps you want.

Things are asyncronous. You wait for things from disk, ram, user input, over the network etc. How long it will take is non-deterministic. So a task composed of a bunch of these little pieces will be non-deterministic too.

I agree with you. I can't be bothered paying 10c to get a "whats up?" text. ~$5 for an episode of the simpsons etc. Pay 100-200 for a phone worth having plus sign up for $50 a month for the next 2-3 years ... no thanks. For me phones are for making phone calls. I spend 90% of my waking hours within 20m of a computer why would I settle for a 4" screen that costs about 1000X more to provide data?

I mostly agree with you but I'd imagine when tuning their algorithms, ie all the time, they have to look at individual emails and see if a manual person would come to the same conclusion that their bot does. They might just test it with their own corporate mail, or have some sort of anonymizing layer that processes the messages first but at some level any mail service will have a IT guy looking at actual messages occasionally. When you are running a separate business process off of the mail you have more reason to need to read emails.

I worked for an antispam vendor and we occasionally (few times a week per developer) had to track down a blacklisting problem which ultimately meant we read the headers and body of the message, did reverse lookups of the senders, pulled mx records from the registries etc. But this is all customer initiated and for their benefit: they want their mail or got spam they didn't think they should have vs us as a vendor reading the mail for our own benefit.

Outlook.com is pretty slick too. For all the gmail users out there worth getting a burner account just to give it a try. I still use gmail as my primary and outlook as my burner but for better or worse MS did a great job giving the Win 8 look and feel to a webmail solution.

It is a matter of business model I think: MS makes money by selling software. Google makes money by selling ads. Both will do whatever steers you towards their profit centres: Google is much more heavily benefited by having detailed info about you, MS not so much they are pretty confident that you'll either want to or will have to use their software.

Really? Unions effectively exist to ensure everyone is treated fair (ie the same). They kick up a stink if anyone mucks with the seniority table that was handed down by God. A lot of non-union workers are the same way: but we do the same work, why does he make more? Heck managers are bad for it too, while in university I worked on a packaging line. We had a lady working with us that was nice but slloooooww. She literally did half of what was supposed to be her job and the guys on either side of her had to do the other 50% to keep the line running. When it came time for employee evaluations I got something like a 92% out of 100% she got 87%. They did at least show the right direction in the comparison but I'd more realistically say it should have been a good 10 points lower for her at least. Another case of people being afraid to being seen as unfair.

Well to be fair, though it would be hard to prove it, if they only problem you have with the employee is that they told Joe they make $5/hr more than them your problem isn't with not being happy with their work. Your problem is now Joe wants $5 more.

It's not necessarily unfair just because it is unequal. Perhaps Bob got a raise because he's a better worker than you. Perhaps he made more money to start because he is seen as having more potential (eg. more experience, more education etc). Everyone isn't the same and ultimately it is up to the employer what they pay, they have to way employee happiness/retention with the value they expect to get from each individual employee.