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.

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

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.

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.

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

    while the latter will almost certainly see me sitting there

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.

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.

8 minutes sounds like something's being forced to load high resolution assets or similar into RAM all at once.

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

And this is how you know the punch card is dead.

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.

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.

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!

If the application is built for large number of customers, one needs to make it fast no matter what!

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.

sleep(7*60) //coffe time

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.

The answer to the question is: it depends on if you consider yourself an amateur or a professional.

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

Best to fix the app!

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

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.