Sponsored categories ask for example how to provide a demonstration on how a sponsor’s product / API can be used. For example “Best BBC. com hack”, or “Best Lonely planet hack”. There are also general categories “Best use of WebApp/widget”, “Best hardware hack”, and the weirdly phrased “Best User Experience / Service Design”.

Sounds cool? Yeah, kind of. But to me such competitions, hackday or hackathon tend to encourage the worse of the typical developer mindset, which is often antinomic to delivering a good UX.

Developer are gods

Developers have advanced skills that allow them to give life to applications: before their work there was nothing, and once they are done, there is something that works. They have the ability, unlike graphic designer or UX people, to create a functioning application on their own. This god-like power on software should not be underestimated.

But the issue is that too often, developer think that the important issue, no, the only important issue, is one of functionality. So the first thing they do when starting a project is jumping on their code editor, and when they manage to have the key functionality part working, they think the application is mostly done, only lacking a superficial layer of polish.

UX is more a differentiating factor than functionality.

This is what this kind of hackaton encourage: the idea that the basic functionality is the most important thing. Well this can very well be true if you are curing diseases, but in the world of software, there is a very strong chance that a competitor proposes or will soon propose the same core functionality. What will really make one product successful over another is its user experience. And you simply can not create a good UX in a day or two.

A frequent developer misconception

This is what Alan Cooper describes in “The inmates are runing the Asylum”) as the “dancing bear” phenomenon, typical of a developer driven mindset: too much focus is on solving a functional problem (“making a bear dance”). No time is spent thinking how to make it dance better, or even why it should be made to dance at all.

This remind me of the time some developer complained about the Siteoverflow.com website, and despised it saying basically he could redo the full site in a weekend. I recommend you read the full reply from Stack Overflow’s Benjamin Pollack, it is well really worth it. The gist of it: there is more than meet the (developer’s) eyes, and by seeing only how to solve the basic functional problem, you ignore all the refinement that make the site actually enjoyable to use, and ultimately successful over its competitors.

Another good insight is Brent Simmons’s “Anatomy of a feature”, where he discusses the inclusion of the “Send to instapaper” command in his RSS reader NetNewsWire. This is another post that was written to placate to developer comments saying “Oh, it’s easy, just a quick http call. I could write a script to do it in like 20 seconds.”
Except implanting this feature involve making a very long list on hard decision on how precisely this feature should work. A menu item? An Icon? How / when does it syncs?…
Eventually, the devil is in the details of the interaction design which end up taking much much more time than solving the basic technical issue.

And neither of those two cases seems to be doing any real User Centered Design, so they risk building their product for themselves instead of for the actual target users. A proper UCD process would have lasted very much longer than the time it took the developer to solve the main technical issue. But it would also deliver a better product, that delight its users.¹

Boys will be boys, and developers will be developers.

Is it an issue that developers love to take part in hackathon, or like to code something just for fun?

Of course not.

Developers will always play around with code, basking in the wonderful pride provided by seeing your application “work”. Instant gratification!
Playing around with new functionalities is one of the best thing about being a developer and this can be a good way to learn new APIs, and simply coding is making them better coders.

Developers and their skills are absolutely necessary to the development of software. We all need them to be the best at what they do, and hackaday, or coding for fun can help with that.
Nonetheless, we need everybody, especially developers, to understand that this is not the way to create quality products.

As always, I’d love to get your feedback on this, especially if you are a developer (or have been in a previous life), so please let me know what you think!

If there was any doubt about the audience being developers, just counting the number of ladies would remove it. I estimate the ratio to be close to 1 woman for 15 guys, a very far cry from the approximate gender parity of UX crowds.

The session were mainly technical, full of info about APIs, (in-)compatibilities, standards etc. Some UX session were also present, but I have to say I was a bit disappointed by them. It’s not that they were not good, far from it actually, special props to Bryan Rieger with his incredibly clean, beautiful, and effective slides. It’s just that given my background in UX and the MSc I just finished, none of this was really news to me: I was simply not the intended audience.

Like any good event, #ota09 got me thinking on a couple of points, that will be the basis of a few blog post.

First up: Hackathons, developer’s conceptions, and how it negatively affect good UX