On premature optimization (HT @edent)

I think a lot of planners are guilty of ‘premature optimization’, a phrase I just read about in this sensible post about whether the tendency of designers to aim at 100% pixel-perfection is really warranted.

Premature optimization was first mentioned by Donald Knuth, computer scientist and professor at Stanford University in a paper about structured programming back in 1974.

To quote:

“Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time:premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”

There are a lot of parallels in the philosophy behind premature optimization and agile development, especially this principle in the agile manifesto: working software over comprehensive documentation. The more we focus on perfecting things (to document them as accurately as possible or not), the more we are likely to overlook essential features that people actually need.

Unnecessary focus on perfection could also mean your idea/project is late to market, possibly behind a competitor’s launch.

Ship, ship, ship.

Nice one, Spotify

I was using Spotify this morning, as I regularly do, and suddenly noticed this information in a corner. Ever since they switched to limiting listening time, I’ve wondered how I’ll know how many minutes and hours I’m using. I sort of assumed that at the end of the limit, I’d be rudely presented with a ‘your time is up’ notification. I’m really glad they’re making it transparent right from the beginning – being friendly rather than dictatorial. Good job, Spotify.

And good luck with your impending US launch next month (even if I first heard Daniel Ek mention the launch over 2 years ago at SXSW!).

Small touches

Really nice features I noticed on Ben Hammersley’s blog that I haven’t seen on any others so far: a note that lets you know the average reading time of blog posts, and a ‘send to Kindle’ button.

Solutions looking for problems

This article has an interesting matrix comparing a user’s desire to complete a task, to the level of complexity required to complete it. The idea is to design services using effective intelligence. The context:

Start-ups often experience a shock when they emerge from the hothouse of heads-down development. Their intended customers barely have time to listen to their idea, let alone devote time to explore its features. The contrast between a small group of friends working intensely together on a single project with the varied needs and limited free time of their customers can be a disheartening experience.

Projects often fail not because the idea is bad, but because the value their service will provide is not easily understood. The question I ask my team is “What problem, from the user’s point of view, are you solving?” It has to be a problem the user knows they have. If the problem is not obvious to the user, in terms they understand, the solution doesn’t matter. Focusing on the problem keeps a project from drifting into fantasy requirements: solutions looking for a problem.

‘Solutions looking for a problem’ – this is what every single one of us, and especially agencies, should avoid proffering. God knows there’s enough rubbish online already.

Nice one, Hootsuite!

I do think the copy is cute, but more than that, I think not logging me out without asking is an extremely good usability feature. I’m not really a fan of Hootsuite, but you have to admit this little thing is lovely.