Is coffee a good excuse for a slow application start-up time?

  • I was dragged into a meeting with a client to consult on any usability issues as we watched a user performing day-to-day operations with a software application.

    The first thing that happened was that after the client double-clicked the app's icon we waited around 8 minutes for the app to load. No one in the room cared about that but me. They argued that what they do is start the application and have coffee while it loads.

    Of course the user believes that the application is fancy, heavy and complex enough to load faster (and in many ways it is), and (of course) I couldn't argue (verbally) that the loading-times could improve inside that meeting with that user, so I wrote 3 technical recommendations to work-around the slow start-up time and presented them to key stakeholders. The suggestions were disregarded on the spot, as the customer didn't care about its slow loading times, since that's their time for coffee.

    I know we should watch how our users work every day, but does that include coffee (or other activities that don't impact the business process directly)? Is this a good excuse?

    Computer with Integrated Coffee Machine

    Edit: added an illustration :)

    No. no, noo. Please no. Nooooooooo.

    8 minutes, are you serious? You mean 8 seconds right?

    @BartGijssens You can never get good coffee in only 8 seconds! :)

    @BartGijssens: Don't be so quick in your judgement. Our client takes seconds to load, but our server can take from 1 minute up to 6 hours (yes hours!) to load depending on the configuration and sheer volume of data it loads into memory. 8 minutes for a client facing app is indeed a lot, but whether it is acceptable or not depends on what it is actually doing. And splitting it up into a quick loading client and slower loading server may just not be worth the effort.

    I'm curious why they just don't leave the computer on and the app running 24/7...

    If the startup time is due to anything other than loading huge amounts of production data; this is also a development issue since every time you make a change you have to wait 8 minutes to see if it worked. This can quickly add up to a large amount of billable time being wasted.

    Build in some Wake-on-LAN functionality so the machines all start up 8 minutes before people get to work.

    If you ask clients a stupid questions, then you can expect to get a stupid answer.

    @JonW there's a couple of clicks that need to happen in minute 4... Just to make things worse...

    Fix the problem first. After, if the "problem" is the time for coffee, put a big sleep and a button "skip" with a captcha. :)

    The problem starts after they've had their coffee. Then the client will start to feel kludgy and unresponsive.

    As a curiosity: Back in the old days (before the exceptionally fast Turbo Pascal compiler) **programmers had abs**. They had to do _something_ while their code compiled. ;-) Take a look at this article by Joel Spolsky

    Is it possible to make the two questions at the end clearer? It looks like people are reading differently your question. Some answers seem to answer "is a slow application a good excuse for coffee?", others seem to answer "is coffee a good excuse for a slow application?". I also don't understand what your first question ("does that include coffee?") is about. Are you asking if you should watch the user while he takes coffee?

    *Coffee* isn't a good excuse, but *Java* is usually a valid reason for slow starts.

    Lemme guess: CATIA? :p

    -= sheer greatness =- (+1 & fav.)

    Hey, 8 minutes is enough to process terabytes of data, not start one shitty app. Even the most complex software, like Blender or Netbeans load well under a minute. Tell the programmers to write a better code.

    What is scary is when an application's start-up splash screen has an indeterminate (barber-shop) progress bar. But 8 minutes! Even worse, my PC has an application that after I say to exit the program, it throws up a modal dialog asking if I really want to exit (even though the application has no ability to save anything), and when I click OK, shutting down the application, a splash screen (with a barber shop pole progress bar) tells me it is shutting down! It could have just closed the window and took 5 minutes to shut down; I didn't need to know.

    Wow that illustration is awesome!

  • To me, the basic logic is this:

    It's better to have a fast app than a slow app. While there are many studies that show that faster applications provide better UX, it seems pretty axiomatic to me. I mean, generally in life if we want something done, then we prefer it to be sooner than later (with the exception of various aesthetic and, um, other activities where the point is enjoying the process... I doubt that an application loading is such a process although sometimes it can be made one).

    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. If it were free and you could do it with a click of a button, then I think the answer would be clear - you ought to do it. But it's not free, so it comes down to cost-efficiency. If you can invest your resources in something that the user does want, do that (provided it's the only user of the app etc. etc., as @yisela says). But if you have the resources available for this at a low cost, do something that would make the app objectively better - speed it up.

    *Sometimes making specific processes slower can achieve specific UX goals. There was a famous case study where some process, probably saving or performing a calculation, was made instantaneous for a new release of a product, and users, who were accustomed that it takes time, weren't sure whether the process ever took place in the new version. This created a lot of confusion and they pressed the button over and over just to make sure it worked. So the developers pretended to slow it down by providing a quick loader or a progress bar or something, which helped put the users at ease. I can't find the link right now. But this is not the case here.

    It may well be that the app is incredibly fast after the load. That is the case with our server. It is fast in responding to queries because of the "slow" load where it loads all data into memory...

    I have been asked to slow applications down for just this reason. We ended up forcing an animated GIF in there with an animation of the process 'working' on a timer of a few seconds even though the task was near-instant, so you have a good point here. Also, +1 for use of 'Axiomatic'; that's a first on this site!

    @MarjanVenema Why don't you just cache the data you use (and read-ahead in the background)? Then you'd have a fast start-up **and** fast queries.

    @BrendanLong: Who says we aren't? We are talking about data volumes of a mere 10 up to well over 200 GB (yes, Giga bytes). No matter how far and much you optimise that, it is going to take time...

    Careful; the issue here is a non-technical one. People using this app aren't self-employed and, as employees, seem to enjoy their free morning ‘coffee’ time. (Should I link to Don't mess with people when they ask you not to, unless you are sure you understand the social dynamics involved.

    I love the part of "um, *other* activities"... haha :)

    "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." That's an excellent way of putting it!

    i personally don't like it if a card transaction is processed instantly, taking a little time implies a more solid and therefore seemingly secure process, regardless of whether the time has any bearing on the actual security

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM