The Hack Stops Here

In my view there are two types of hacks:

  1. Solutions that solve a problem that can’t be solved any other way (i.e. due to a limitation within a browser).
  2. Solutions to business created problems.

Hacks for the first type are acceptable. They go where no other code can go, and are a requirement. As such these types aren’t really hacks – they’re just sneaky, ninja-type bits of code.

The second type happens in two situations:

  1. When a last minute detail has cropped up and there’s no other way to do the task quickly enough.
  2. When a business decision has been made that forces the hand of the developer to hack a solution.

There are always exceptions, but those aside: it’s this last type that I (now) refuse to develop.

Facebook Friends Import

If you’re not familiar with Facebook get out from under your rock. One “feature” that’s being discussed in the blogging World right now is the ability to import friends from Hotmail or Gmail.

This concept is great. However, the actual implementation of importing your friends is appalling. It requires the user to enter their username and password to the particular service to import the data.

This is a hack. A hack driven by business.

Jeremy Keith points out that this kind of hack teaches people how to be phished.

This functionality is nothing new, for years we’ve been able to write code that can log in and cache the cookie to continue to programmatically navigate through a system (LWP springs to mind) – but we didn’t (or you shouldn’t have. Bad dog).

Lead By Example

The big problem is that Facebook is such a big entity on the Internet that it’s seen to leading the way. In the words of 37 Signals:

No wonder other sites have been racing to implement similar features

If you’re in a position of authority, others will listen to you, and if you show them the right way of doing things, then you’re on to a winner.

If, on the other hand, you show them the wrong way of doing things (see Twitter’s new invite system) you’re starting a virus.

As a general rule: if it’s questionable, then it probably shouldn’t be written.

What do you think? Do you find yourself being bullied in to hacking solutions, or do you think hacking up the Internet is the way to go – and more importantly: why? Or is your approach do the right thing?

Hacking can be hazardous to your heath

9 Responses to “The Hack Stops Here”

  1. Interesting post. Is there a correct way to implement this functionality that you’re saying facebook have been negligent by not following?

  2. Since there’s no Google API (right now) that allows you to pull a users contacts, then no. Since the answer is no, I believe, really the functionality shouldn’t be there.

    It’s a great way to find your friends, but it get users used to something that shouldn’t be available in the first place. There’s so many phishing sites out there, that if you tell users it’s okay to put your details in to a trusted web site like facebook, then they’ll be less wary when it’s a malicious site.

  3. Well said sir!

  4. I completely agree (and wrote an article about this very problem for .Net Magazine), but I can also understand reluctance to remove those invitation processes from the business side. Twitter’s recent meteoric rise to the mainstream may have been lubricated in part by the ease with which people can invite their friends using their (still broken) invitation process.

    To play devil’s advocate for a moment and use an extreme example, would you rather have the current situation, or one where Twitter and Facebook hadn’t become successful because the burden of manually inviting one’s friends was too much of a hurdle for a mainstream audience to bother with?

    Caveat: I’m not actually advocating them, just posing what the business argument would likely be if they were to join this conversation.

  5. @Paul – aye, and I’m saying that these anti-patterns are type 2-2 – which *I* personally refuse to build – at the time, I was still being asked to both build these and how to build these. I won’t propagate a broken idea. Someone else can :)

  6. As a developer, refusing to develop business-oriented hacks would lead to me being fired; If I can’t do what I’m told they’ll find someone who will.

    Of course I’ll always try to talk people out of it, and often that works, but not always.

  7. Although I completely agree with the notion, it’s quite difficult do make that refusal.

    How do you tell the client ‘your idea is a bad idea’, and that we won’t do the work out of our ideal view of the Web?

    And they say that designers are difficult to communicate to.

  8. @Tony – I’m a strong believer in delivering a product for clients whilst the client is technology agnostic. i.e. why would the client be telling you to write code that does xyz – that’s like telling a designer than they should be using rounded corners or a big pink font. It’s your experience they’re paying for, make sure you’re providing that. Anyone can write code, and if the *way* the client wants something solved requires you to create hack code that’s going to trick users in to giving out sensitive details, it’s your job, with your experience to find another way of executing the same effect. Take Dopplr for example – they’re able to find your suggested friends without having asking for your username and password. Sure, it’s a little more work on their side, but at least I’m not handing over sensitive information to an initially untrusted web site.

    @Pete – if you’ve got a manager, that codes too, then yep you’re right – but you’ve got the right idea: explain why it’s a bad idea. If they’ve got all the facts in front of them (and hopefully you can offer an alternative rather than just “it sucks”), they’re able to make the right decision. Sometimes the business will chose the right route too – sometimes not – I understand business needs over resources available – but you’re giving them the options, so you’re helping to make the situation better :)

  9. @Remy – that sounds about right. I guess as designers and developers we do have the responsibility to make sure we’re not leading the client down the path of tricking users. There are always other alternatives. We just have to learn to communicate it better. Thanks for the advice!

Leave a Reply
Not required

CODE: Please escape code and wrap in <pre><code>, doing so will automatically syntax highlight