2

Situation: a piece of software reads frames of data from a file in a seperate thread and puts it on a queue, emptied by another thread. That second thread periodically checks on the queue and fails rather gracefully, by showing an error message stating the read timed out, if no data is available within a certain amount of time. Initially this timeout was set to 200mSec. There was no real reasoning behind that constant though, but it worked fine. We measured on a couple of machines and for large data frames, larger than what would be used by customers, a read took like 20mSec whith no other load on the machine.

However one customer now gets timeout errors now and then (on the second try all is fine, probably the file is in cache or the virus scanner leaves it alone). The programmers are like 'well, yeah, but that customer's machine is full of cruft, virus scanners, tons of unneeded background processes etc'. Of course the customer is like 'hey this should just work, shouldn't it'? While the programers have a point, since the software is heavy enough to validate the need for a dedicated machine, that does not make the customer happy.

Increasing the timeout to 2 seconds, for example, solves the problem. But I'd like to make a proper decision now instead of just randomly pick some magic constant that is probably ok in 99% of cases. What criteria should be used for that? We could just pick a large number, but that feels wrong. (and then we end up with a program that has the horrible bahaviour of hanging when trying to read from a disconnected drive for instance, whereas we'd rather make it show an error right away). Or we could make the timeout value a user setting, but then we need to ducument it clearly and even then not all customers are tech savy enough to really understand what it does. Or we could try and wait until another customer reports timeouts and increase the value again. And again. Until we find something ok for 99.99% of the cases.. Any good practice for this type of situation?

Improve this question
3
  • What is the purpose of the timeout? Why not wait as long as it takes? Are there identified circumstances under which the operation would take a long time and waiting is the wrong thing to do? (If nobody has any idea what the timeout is for, and it's breaking things, get rid of it.)
    – David Schwartz
    Oct 12, 2012 at 11:08
  • 'as long as it takes' might as well be infinite in case of network problems. So without further modifications, the user would just see the application is reading from the file but nothing else, infinitely. That's not exactly a nice user experience.
    – stijn
    Oct 12, 2012 at 11:42
  • So the purpose of the timeout is to prevent the user from waiting forever? That suggests two things immediately: 1) The timeout should be about how long before a human would likely not want to wait any longer, at least two seconds. 2) The human should be allowed to continue waiting if they wish. (200ms network timeouts are pretty crazy, IMO. TCP will often deliberately delay 200ms.)
    – David Schwartz
    Oct 12, 2012 at 11:51

2 Answers 2

Reset to default
4

It's very similar to performance non-functional requirements: how can you tell that a specific process should take 100 ms., or 500 ms., or maybe 10 seconds? The answer is the same: it's up to the stakeholders to decide, after being advised by interaction designers.

It's also the work of an interaction designer to make the application feel responsive in your case. If the timeout is increased to 2 seconds, it doesn't mean that in a case of a disconnected drive, the application should completely hang during this time. It's difficult to be more detailed, but here's an example of user experience I can imagine:

  1. I'm doing something which starts the action you describe. This action has a timeout of two seconds.

  2. Given that on ordinary cases, the action takes approx. 20 ms., nothing is displayed during the first 100 ms.

  3. Let's say I experience local network connectivity issues. After those 100 ms., the application shows an animation indicating that it's currently doing something. Optionally, a cancel button may be shown too.

  4. If the file cannot be accessed after two seconds, the application apologizes to the user, explains why it cannot work as expected and what the user may do to help the application work as expected again.

  5. While showing this, the application checks in loop if the file is still unavailable. If the connection is back, the application informs the user that the issue is solved.

Improve this answer
1
  • +1 that is a quite nice scenario and solution. Though the question still remains then: how do you pick those values, 100mSec, 2 seconds? Just measure a couple of use cases and take the mean plus some safety range?
    – stijn
    Oct 12, 2012 at 11:45
3

I wouldn't overanalyse this one. I would opt for the user setting. This way you or your helpdesk will be able to help a customer on the fly without any hassle.

If you need to help customers adjust this setting lots of times it's time to automate it. You could use some heuristic like increasing the timeout value each time a timeout occurs, remembering the value that does work etc...

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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