Like many things in life and this example chaos gets in the way.
As we all know at supermarket checkouts and the delima of which queue to join there are many factors that can make what appears to be a shorter and faster queue to join suddely bottleneck and make you regret your choice.
1) Customer slow packing - many factors for this.
2) Customer slow paying - digging out their payment method or issue with payment method.
3) Customer has a question that creates another queue factor that is waiting for a manager - return, error at checkout (reduction not processed and needs manager to use their magic key to authorize change)
Those just 3 example and the whole art of which queue to join becomes an ongoing art form. Of note, I just stick with the queue I'm in unless there are signs a new queue/checkout will open suddenly (that's another skill of recognising those signs as well as what that checkout will be and can often be case of picking no queue knowing a new checkout will open iminatly and what one it will be)
Equally I'm sure many have their own stratergy for which lane of traffic to join and garantee everyone will have instances of them changing lanes to a faster moving lane only for that lane to slow down and the lane they left suddenly become the one moving.
Software is no different as it interacts with users and us humans all add are own level of chaos to the equation. Gets down to managing the peaks and resources to handle those peaks. Though however well you plan, there will always be that chaos moment like suddenly being top of HN as a fine example of sudden exception spike.
Sure you can plan and budget for every possible spike but when those resources are idle you are paying the price and again, gets down to a fine balance. After all, for every rule of planning you put in place, there will always be an exception that bites you.
Being able to manage expectations and smoothing out those spikes and informing of delays and expectations can help a bit though can also for some, be just as bad. After all - we have all had experiences of being on hold in some call system being told we are X in a queue and see that level of movement in that queue change from we are 10 in the queue and after a cople of minutes we are now 3 in the queue, then those 3 take ages so after ten minutes your only 2 in the queue. So whilst feedback of expected waits can be helpful, they do set a level of expectation that can also become detrimental in such situations. With those, callback systems work best, though in software, and more so client interaction that can be hard. Imagine if you went to a site and instead of a 404 it would say, sorry too busy currently but we will push the content to you once we are able. That for many wouldn't work on many levels, let alone the code to handle and manage that. So you get a stage of managing and scaling best you can, but being able to gracefully manage when those limits break is just as if not more so important than planning and resourcing those queues in the first place.
So being able to manage expectations is always and if not more important. Maybe why the old engineering art of saying it will take 3x longer than it will holds up so well as if people are initially advised of a delay - whilst they may be upset, they will still understand and if that expectation of a delay of 10 minutes is over estimated and they find it was only 3 minutes then they will come away more positive. Equally advising them it will take what you expect and say 3 minutes and it turns out to be 10 minutes or you keep pushing that delay with notices (delays upon delays) then the overall experience will be very tainted more than had you over-estimated in the first place.
As we all know at supermarket checkouts and the delima of which queue to join there are many factors that can make what appears to be a shorter and faster queue to join suddely bottleneck and make you regret your choice.
1) Customer slow packing - many factors for this. 2) Customer slow paying - digging out their payment method or issue with payment method. 3) Customer has a question that creates another queue factor that is waiting for a manager - return, error at checkout (reduction not processed and needs manager to use their magic key to authorize change)
Those just 3 example and the whole art of which queue to join becomes an ongoing art form. Of note, I just stick with the queue I'm in unless there are signs a new queue/checkout will open suddenly (that's another skill of recognising those signs as well as what that checkout will be and can often be case of picking no queue knowing a new checkout will open iminatly and what one it will be)
Equally I'm sure many have their own stratergy for which lane of traffic to join and garantee everyone will have instances of them changing lanes to a faster moving lane only for that lane to slow down and the lane they left suddenly become the one moving.
Software is no different as it interacts with users and us humans all add are own level of chaos to the equation. Gets down to managing the peaks and resources to handle those peaks. Though however well you plan, there will always be that chaos moment like suddenly being top of HN as a fine example of sudden exception spike.
Sure you can plan and budget for every possible spike but when those resources are idle you are paying the price and again, gets down to a fine balance. After all, for every rule of planning you put in place, there will always be an exception that bites you.
Being able to manage expectations and smoothing out those spikes and informing of delays and expectations can help a bit though can also for some, be just as bad. After all - we have all had experiences of being on hold in some call system being told we are X in a queue and see that level of movement in that queue change from we are 10 in the queue and after a cople of minutes we are now 3 in the queue, then those 3 take ages so after ten minutes your only 2 in the queue. So whilst feedback of expected waits can be helpful, they do set a level of expectation that can also become detrimental in such situations. With those, callback systems work best, though in software, and more so client interaction that can be hard. Imagine if you went to a site and instead of a 404 it would say, sorry too busy currently but we will push the content to you once we are able. That for many wouldn't work on many levels, let alone the code to handle and manage that. So you get a stage of managing and scaling best you can, but being able to gracefully manage when those limits break is just as if not more so important than planning and resourcing those queues in the first place.
So being able to manage expectations is always and if not more important. Maybe why the old engineering art of saying it will take 3x longer than it will holds up so well as if people are initially advised of a delay - whilst they may be upset, they will still understand and if that expectation of a delay of 10 minutes is over estimated and they find it was only 3 minutes then they will come away more positive. Equally advising them it will take what you expect and say 3 minutes and it turns out to be 10 minutes or you keep pushing that delay with notices (delays upon delays) then the overall experience will be very tainted more than had you over-estimated in the first place.