
Is coffee a good excuse for a slow application start-up time? - charliesome
http://ux.stackexchange.com/questions/29181/is-coffee-a-good-excuse-for-a-slow-application-start-up-time
======
srean
In additional to personal preferences, cultural predispositions too play a
role in this particular decision process.

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.

~~~
kiba
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.

------
meepmorp
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.

------
thaumaturgy
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."

~~~
Evbn
Like MacOS infamous "it feels snappier" and "rebuild permissions" after each
OS update.

------
saurik
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.

~~~
praptak
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
:)

------
georgemcbay
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.

------
njharman
[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.

------
Shank
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.

~~~
mseebach
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)

------
spyder
Is it slow because of this coffee? : <http://goo.gl/GPDSh>

~~~
wtracy
I looked at the headline and actually expected this to be some rant about
performance in CoffeeScript.

------
tsahyt
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".

------
sramsay
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?"

~~~
derleth
> 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.

------
eyevariety
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.

------
kevinconroy
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.

------
6ren
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!_

------
rajanchandi
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!

------
brudgers
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.

------
cristiantsara
sounds like some employee hid this code somewhere

sleep(7*60) //coffe time

~~~
z3phyr
(sleep (* 7 30)) ;; coffe time

------
wavesounds
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.

------
skriticos2
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.

------
rizzom5000
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.

------
daniel-cussen
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 :)

~~~
ht_th
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.

------
fudged71
This is culturally fascinating as much as it is technically hilarious.

------
chris_wot
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!

------
eob
You know what they say, Works Slowly > Breaks Quickly

------
iamtherockstar
"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).

~~~
byoung2
_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.

------
drivebyacct2
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.

