Is coffee a good excuse for a slow application start-up time?(ux.stackexchange.com)
ux.stackexchange.com
Is coffee a good excuse for a slow application start-up time?
http://ux.stackexchange.com/questions/29181/is-coffee-a-good-excuse-for-a-slow-application-start-up-time
25 comments
I presume "engineering tolerance" means increased quality over time?
Inefficiencies like that bother the hell out of me, and will nag me no end.
Right on! I wish hollywood have that kind of attitude toward inefficiency too. It's quite maddeningly to me the way they think. I just can't understand them.
Inefficiencies like that bother the hell out of me, and will nag me no end.
Right on! I wish hollywood have that kind of attitude toward inefficiency too. It's quite maddeningly to me the way they think. I just can't understand them.
I'm reminded of the (probably apocryphal) story of how IBM did a trial outsourcing of some electronics manufacturing to Japan, back in the 50s or 60s when this was considered risky. Their contract specified a 3% defect rate, which was considered very low at the time.
Months pass and IBM gets their order delivered in big crates. They pop one open and find that some of the parts are stored in a bag at the top. There is a note attached, which reads: "We do not understand why you desire 3% faulty parts, but for your convenience, we have packaged them separately."
Months pass and IBM gets their order delivered in big crates. They pop one open and find that some of the parts are stored in a bag at the top. There is a note attached, which reads: "We do not understand why you desire 3% faulty parts, but for your convenience, we have packaged them separately."
I've seen app load times this bad before (longer, actually, in the 15-20 min. range), on a VB6 fat client app that hit a central network db server.
This was actually indended to be an improvement. The app was meant to replace an existing point of sale system in a national chain of stores, but because the app was purchased by executives which no real understanding of what they were getting (and who browbeat anyone who tried to raise warning flags as being protective of their own fiefdoms) it had some architectural/programming warts which made it doomed to fail.
For example, all clients were to use a central database, located at company HQ, typically over 128kbps links. The legacy system used servers in each store, with sales and inventory data being passed up incrementally, so the slow links weren't an issue. And the code base was terrible - littered with select * over tables with hundreds of columns just to fetch a couple fields. Because development had been so haphazard on the app, nobody wanted to remove fields from the db, just in case they were used someplace. And these selects happend all the time, like when you'd click a UI item and it'd fetch the relevant data on demand to populate stuff. There were tons of other issues, too - like being unable to handle most transactions without the network and db being available, integrity issues, etc. It was a mess.
So, once it became clear that the app was gonna fall over entirely on deployment to more than about 10 clients, panic mode set in. After some guessing, the developers decided to cache data on startup. Hence the slow as fuck startup times as each client performed thousands of selects of hundreds of fields to get enough data to run. It actually helped, somewhat, though all of the other issues were enough to utterly doom the app and get the executive (CFO, I think) who bought it shown the door. A major US consulting firm came in and replaced it, costing craploads but actually delivering something usable.
This was actually indended to be an improvement. The app was meant to replace an existing point of sale system in a national chain of stores, but because the app was purchased by executives which no real understanding of what they were getting (and who browbeat anyone who tried to raise warning flags as being protective of their own fiefdoms) it had some architectural/programming warts which made it doomed to fail.
For example, all clients were to use a central database, located at company HQ, typically over 128kbps links. The legacy system used servers in each store, with sales and inventory data being passed up incrementally, so the slow links weren't an issue. And the code base was terrible - littered with select * over tables with hundreds of columns just to fetch a couple fields. Because development had been so haphazard on the app, nobody wanted to remove fields from the db, just in case they were used someplace. And these selects happend all the time, like when you'd click a UI item and it'd fetch the relevant data on demand to populate stuff. There were tons of other issues, too - like being unable to handle most transactions without the network and db being available, integrity issues, etc. It was a mess.
So, once it became clear that the app was gonna fall over entirely on deployment to more than about 10 clients, panic mode set in. After some guessing, the developers decided to cache data on startup. Hence the slow as fuck startup times as each client performed thousands of selects of hundreds of fields to get enough data to run. It actually helped, somewhat, though all of the other issues were enough to utterly doom the app and get the executive (CFO, I think) who bought it shown the door. A major US consulting firm came in and replaced it, costing craploads but actually delivering something usable.
So many different ways to look at this.
An eight minute load time on even barely modern hardware is generally unacceptable. That would be an application smell to me -- a sign that the application's code base is needlessly complex and will be prone to frustrating and difficult-to-troubleshoot problems later.
On the other hand, the client doesn't care. They've found a good use for the time. In terms of billable time, if the client doesn't want to pay for better performance, then it's hard to argue in favor of spending any effort fixing that.
It does kind of present an opportunity too. If you can have a long term relationship with this customer, then you can roll out subsequent versions in which you fix a little bit of what's wrong with the startup time in each version. The customer will feel like they're getting faster software with each update, which would be a pleasantly unique experience for the user.
Or, just let someone else come along and tell the customer the same thing that everyone else in I.T. says: "This application is slow, you need more expensive hardware."
An eight minute load time on even barely modern hardware is generally unacceptable. That would be an application smell to me -- a sign that the application's code base is needlessly complex and will be prone to frustrating and difficult-to-troubleshoot problems later.
On the other hand, the client doesn't care. They've found a good use for the time. In terms of billable time, if the client doesn't want to pay for better performance, then it's hard to argue in favor of spending any effort fixing that.
It does kind of present an opportunity too. If you can have a long term relationship with this customer, then you can roll out subsequent versions in which you fix a little bit of what's wrong with the startup time in each version. The customer will feel like they're getting faster software with each update, which would be a pleasantly unique experience for the user.
Or, just let someone else come along and tell the customer the same thing that everyone else in I.T. says: "This application is slow, you need more expensive hardware."
Like MacOS infamous "it feels snappier" and "rebuild permissions" after each OS update.
FWIW, I'd personally be happier (at least for an app that was sufficiently stable that I didn't find myself having to start it many times a day) with an eight minute load time than a thirty second load time: the former makes it quite clear to me that I shouldn't sit around waiting for it (which means I will definitely do something else, and come back sufficiently later that it will be over) while the latter will almost certainly see me sitting there staring at the app, frustrated, waiting out the thirty seconds.
Indeed, sometimes "bad but not enough to do something about it" is worse than "unacceptably bad". Broken central lock will get fixed immediately, broken driver's door lock will make the owner crawl over the passenger seat for weeks :)
I could picture myself reacting exactly as described. It's a good point.
This, literally. Back in my days programming at a banking institution, the COBOL mainframe programmers used to boast a 'better quality of life' and 'reduced anxiety' with their 5min jobs than us in the C team with our 30s compiles.
while the latter will almost certainly see me sitting there
It would be nice to know a bit more about what is happening in those 8 minutes... is the app doing actual work like recreating state from a transaction journal, or is it just being incredibly cpu wasteful for no real purpose?
If the latter, my professional pride would compel me to improve the startup time regardless of whether it would translate directly into dollars.
The good news is in situations like that (codebases that are just woefully unoptimized to start with) you can often get drastic speed increases with fairly simple changes, if you are clever enough. A bit of on-demand loading here, some basic loop reordering there, etc and now your 8 minute startup is 1 minute or less.
Of course, if the developers were any good with such optimizations the app would never have reached its current state to begin with.
If the latter, my professional pride would compel me to improve the startup time regardless of whether it would translate directly into dollars.
The good news is in situations like that (codebases that are just woefully unoptimized to start with) you can often get drastic speed increases with fairly simple changes, if you are clever enough. A bit of on-demand loading here, some basic loop reordering there, etc and now your 8 minute startup is 1 minute or less.
Of course, if the developers were any good with such optimizations the app would never have reached its current state to begin with.
[Assuming custom software, not shrinkwrap]
Sometimes you have to do what the client needs, not what they ask for (Because they sometimes don't have enough experience, knowledge, etc. to know. That's why they hired you, the expert).
But, this sounds very clearly unneeded feature they client does not want, will not help them, and would be wasting their money to implement.
Even without the coffee excuse, startup time for something that starts up once or even a few times day is going to be low on the bang per buck backlog.
Sometimes you have to do what the client needs, not what they ask for (Because they sometimes don't have enough experience, knowledge, etc. to know. That's why they hired you, the expert).
But, this sounds very clearly unneeded feature they client does not want, will not help them, and would be wasting their money to implement.
Even without the coffee excuse, startup time for something that starts up once or even a few times day is going to be low on the bang per buck backlog.
What I really wish we knew was what application it was. I've never seen that slow of a client booting up, even having worked with fairly heavy applications (AutoCAD and modeling software comes to mind). They start in a matter of 30 seconds to a minute on a subpar box.
8 minutes sounds like something's being forced to load high resolution assets or similar into RAM all at once.
8 minutes sounds like something's being forced to load high resolution assets or similar into RAM all at once.
The culprit almost certainly is hitting a slow server over a remote (ie high latency) network link in a poorly designed pattern (ie for each client, run these fifteen queries - worked fine for the dev with a fast server on the LAN and three test clients in the DB)
Is it slow because of this coffee? : http://goo.gl/GPDSh
I looked at the headline and actually expected this to be some rant about performance in CoffeeScript.
Personally I believe that in most applications, good performance is part of a good UX. 8 minutes of load time sounds like quite a lot but then again I don't know what application this is about and what's actually happening in those 8 minutes.
I'd say: If you've got spare time to work, make it quicker. It can never hurt. Then again, optimizing has become one of my hobbies anyway, I just like to knock off a few cycles here and there (I find that weirdly relaxing).
UX-wise the question is actually not whether it's truly fast, but whether it's "reasonably quick". What is reasonable here? If it's a very complex application, users expect it to load up longer. If it's notepad, nobody wants to wait for an hour for it to load. Or think about a 3D graphics engine. Nobody cares whether it runs at 100 or 150fps, as long as it doesn't go below 60 we're all fine.
On a sidenote I want to tell a story. A friend of mine has been hacking away on some Android ROM based on a modified MIUI and he noticed that it takes ages to install. So he had a look at the sources and found out that the original author had quite a weird way of installing stuff. Basically, what he did was copying the same files multiple times and deleting them again. He was just burning cycles. My friend wrote the author an email, asking why he's doing that. The answer was along the lines of "It looks better if it takes longer".
I'd say: If you've got spare time to work, make it quicker. It can never hurt. Then again, optimizing has become one of my hobbies anyway, I just like to knock off a few cycles here and there (I find that weirdly relaxing).
UX-wise the question is actually not whether it's truly fast, but whether it's "reasonably quick". What is reasonable here? If it's a very complex application, users expect it to load up longer. If it's notepad, nobody wants to wait for an hour for it to load. Or think about a 3D graphics engine. Nobody cares whether it runs at 100 or 150fps, as long as it doesn't go below 60 we're all fine.
On a sidenote I want to tell a story. A friend of mine has been hacking away on some Android ROM based on a modified MIUI and he noticed that it takes ages to install. So he had a look at the sources and found out that the original author had quite a weird way of installing stuff. Basically, what he did was copying the same files multiple times and deleting them again. He was just burning cycles. My friend wrote the author an email, asking why he's doing that. The answer was along the lines of "It looks better if it takes longer".
I don't know the circumstances, but my first reaction was: Eight minutes?! Eight?! Like, can we use those eight minutes to take all the developers out back and have them shot?"
> Eight minutes?! Eight?! Like, can we use those eight minutes to take all the developers out back and have them shot?
And this is how you know the punch card is dead.
And this is how you know the punch card is dead.
Irrespective of his concerns as an individual- from a pure usability perspective: any waiting of any sort that does not signify some valuable piece of information is negative to user experience. We have seen time and time again that web speed optimizations show significant positive change in how people use or abandon different web tasks.
There may be some abhorrent business perspective that uses this loading time as a "this app is so complicated it takes minutes to load" type thinking- but this is pure snake oil. Ultimately being able to use a tool as soon as the need strikes and at a speed as close to your own thoughts as possible is the best user experience. Any decisions that are made (8 minute load time) based on technology contraints tend to impact user experience negatively.
There may be some abhorrent business perspective that uses this loading time as a "this app is so complicated it takes minutes to load" type thinking- but this is pure snake oil. Ultimately being able to use a tool as soon as the need strikes and at a speed as close to your own thoughts as possible is the best user experience. Any decisions that are made (8 minute load time) based on technology contraints tend to impact user experience negatively.
Coffee is not a good excuse for a slow application start-up time.
Should it be fixed? Ideally yes. But in the real world, it depends.
Is the user billed hourly (and therefore do they want you to fix it)? What's the business context? Will it help other users? (Are there other users?) What is the app doing in those 8 minutes and how would reducing it affect (positively or negatively) the user experience after startup?
Yes, getting a faster start time is ideal, but assuming limited resources you need to figure out what the biggest user experience problems are and fix those first.
If you application takes 8 minutes to load, the biggest user problem may well exist AFTER the application has loaded. Fix that first.
Should it be fixed? Ideally yes. But in the real world, it depends.
Is the user billed hourly (and therefore do they want you to fix it)? What's the business context? Will it help other users? (Are there other users?) What is the app doing in those 8 minutes and how would reducing it affect (positively or negatively) the user experience after startup?
Yes, getting a faster start time is ideal, but assuming limited resources you need to figure out what the biggest user experience problems are and fix those first.
If you application takes 8 minutes to load, the biggest user problem may well exist AFTER the application has loaded. Fix that first.
Features vs. Benefits: Features are what your app does; Benefits are what your customers value.
Because engineers always want to make something "better", and they consider that in terms of the product in isolation (not in terms of the customer), they often keep improving features beyond what customers value, and so "overshoot" customer needs.
This is so predictable that it fits into Christensen's "disruption" thesis: e.g. minicomputer manufacturers kept improving their product after PC's appeared. They were always better than PC's (feature), but PC's were soon good enough for their customers (benefit). And so DEC got killed. Today, x86 PC's are better than ARM netbooks/tablets/phones...
If you squint your eyes, you can also see this as a case of premature optimisation ("root of all evil" and "don't; not yet").
now with coffeetime™ technology!
This is so predictable that it fits into Christensen's "disruption" thesis: e.g. minicomputer manufacturers kept improving their product after PC's appeared. They were always better than PC's (feature), but PC's were soon good enough for their customers (benefit). And so DEC got killed. Today, x86 PC's are better than ARM netbooks/tablets/phones...
If you squint your eyes, you can also see this as a case of premature optimisation ("root of all evil" and "don't; not yet").
now with coffeetime™ technology!
I think it is about priorities.
If loading speed is not a priority for the client, we need to know what is their priority? Try to address the priority first and then focus on making it faster.
If the application is built for large number of customers, one needs to make it fast no matter what!
If the application is built for large number of customers, one needs to make it fast no matter what!
Thought experiment:
Let's suppose that load time could be halved. Four minute load time means that employees will still spend the same fifteen minutes getting their coffee.
Even an order of magnitude improvement in load time would be over a minute and long enough to justify checking Facebook on one's iPhone. The fifteen minutes is still lost - maybe more because at a minute of load time, people might wait until they have their coffee before starting the application.
Let's suppose that load time could be halved. Four minute load time means that employees will still spend the same fifteen minutes getting their coffee.
Even an order of magnitude improvement in load time would be over a minute and long enough to justify checking Facebook on one's iPhone. The fifteen minutes is still lost - maybe more because at a minute of load time, people might wait until they have their coffee before starting the application.
sounds like some employee hid this code somewhere
sleep(7*60) //coffe time
sleep(7*60) //coffe time
(sleep (* 7 30)) ;; coffe time
I had this exact same "we take our coffee break while this is loading" experience.
However it wasn't our code and we ended up fixing it, for free to the client and actually at a non-insignificant expense to us, because we wanted to show the client that we were better then the previous vendor in hopes of winning more of their business down the line (which we did).
So if you don't fix it you leave yourself open to competition.
However it wasn't our code and we ended up fixing it, for free to the client and actually at a non-insignificant expense to us, because we wanted to show the client that we were better then the previous vendor in hopes of winning more of their business down the line (which we did).
So if you don't fix it you leave yourself open to competition.
I have first hand experience with big enterprise shops. Pretty much all apps behave like this. Everything is slow, including the platform. Nobody cares.
The result is, it totally kills productivity.
Any app that takes 8 minutes to load will only be loaded if absolutely necessary. By then you'll forget what you wanted to do anyway in a busy business day.
No, it's not a good excuse. If you outlined three ways to improve performance and nobody budged, fine, but that doesn't make it acceptable and if I were the application architect I'd be embarrassed - and the others who declined to look into your proposal should be as well.
The answer to the question is: it depends on if you consider yourself an amateur or a professional.
The answer to the question is: it depends on if you consider yourself an amateur or a professional.
From a technical perspective, this is bullshit, bullshit, bullshit.
But this is a UX question. I could see there being unintuitive nonlinearities with how a user responds to load times. Coffee, too, can be very important to user experience. I'll allow it :)
But this is a UX question. I could see there being unintuitive nonlinearities with how a user responds to load times. Coffee, too, can be very important to user experience. I'll allow it :)
Yes, with waiting time there seem to be a zone of frustration. Waiting a short time isn't a problem. Waiting a long time, i.e., 8 minutes gives me ample time to do something else,like, getting a coffee. However, a waiting time in between is frustrating as I am waiting wasting my time, and I know it.
This is culturally fascinating as much as it is technically hilarious.
Look, management was probably in that meeting. They probably don't use the application. The users, in the meanwhile, are going insane over the slow load times.
Best to fix the app!
Best to fix the app!
You know what they say, Works Slowly > Breaks Quickly
"The customer doesn't object to the app being faster, he just doesn't care. That's a big difference. If you make it faster, he won't come to you asking to slow it down because now he doesn't have time for coffee.
So, this is something that you generally ought to do, but you don't really need to."
I struggle with this personally. There are lots of things I ought to do, but don't schedule time for because they don't have a very compelling business reason to do so. The customer is happy enough to continue handing over the money at the rate that they are, and aren't likely to hand over more money if you make it faster (though a slow app could prevent new customer acquisition).
So, this is something that you generally ought to do, but you don't really need to."
I struggle with this personally. There are lots of things I ought to do, but don't schedule time for because they don't have a very compelling business reason to do so. The customer is happy enough to continue handing over the money at the rate that they are, and aren't likely to hand over more money if you make it faster (though a slow app could prevent new customer acquisition).
The customer is happy enough to continue handing over the money at the rate that they are, and aren't likely to hand over more money if you make it faster
You have to be prepared for a competitor to come along and create a faster version, at which point your customer might suddenly realize that he needs a faster app.
You have to be prepared for a competitor to come along and create a faster version, at which point your customer might suddenly realize that he needs a faster app.
Yes, but my understanding was that this software was for one specific client.
Is there a (good) reason for it to take 8 minutes? If not, I'd be seriously concerned about what else is broken/wrong/unoptimized when a user expects it to be reliable.
A lot have been written about Japanese auto manufacturers continuing to reduce engineering tolerances even in the absence of externally enforced market demands. This has often been contrasted with the American auto manufacturer's purported management style where they would only meet the level of tolerance necessary (for assembly and finished product quality) but no more. Anything more was perceived as wasteful and misallocation of resources. I do not know how much truth is there to those stories.
I guess the answer depends on where in the spectrum of business vs pleasure does the act of coding lie. Even for business software, it hardly ever lies in the "purely business" extreme. Or so I would like to think. Inefficencies like that bother the hell out of me, and will nag me no end.
Many live with Eclipse regardless of its startup time.