Programmers love to make their lives difficult

When starting out with Mac development, I turned to Aaron Hillegass’s Cocoa Programming for Mac OS X, and compared to other books available on the subject I was very pleased with it. One point that he made in the opening chapter has pretty much remained true whilst I’ve been developing under OS X with the Cocoa frameworks:

Most of the time, Cocoa fulfills the promise: Common things are easy, and uncommon things are possible. If you find yourself writing many lines of code to do something rather ordinary, you are probably on the wrong track.

And I don’t think that this is unique to development with Cocoa – a lot of libraries these days promote ease-of-use for the developer.

However, it seems that a lot of programmers love to make their lives more difficult, by not thinking about what they’re doing to solve a problem, and go in blind to find something that works – perhaps as trial and error because they are not familiar with the area they are developing for  – but which makes more work in the long-run by being harder to maintain.

The other day I was browsing the website of European cinema chain Odeon to look up times for a film. I was appalled to see that the “Book Now” form in the right-hand column of the page was implemented using Flash.

I wondered what on Earth was going through the developer’s mind when he (or she, but I’ll keep it simple) decided to implement a bog-standard HTML form by going for something Flash-based. All the features of the form could be easily implemented in HTML and Javascript (there were no fancy effects) – and if the argument there was along the lines of “Yes, but what if Javascript is turned off?” then surely Flash would be a no-go too?

What made it even more annoying was that in his haste to make his life more difficult, he forgot to implement scrolling of the combo box options using the mouse wheel, which when I went to scroll the list caused scrolling of the page instead. So, basically, what the developer has done here is:

• Provided a less than adequate visual appearance (at least compared to what would otherwise be there with an HTML form) which doesn’t look like a “native” combo box.
• Implemented different behaviour than would otherwise be implemented if using an HTML form, thus causing confusion and annoyance.
• Re-implemented something that could be done easily in HTML, with about 3 times as much effort.

If he had just stuck to HTML, CSS and Javascript then there would be a cleaner experience for the user, and one less dependency in the project. It just seems like such a redundant decision.

I often talk about this when people ask about subclassing in Objective-C/Cocoa for the Mac or iPhone. Unlike some other libraries, the Cocoa frameworks promote extension through interaction with the classes, rather than subclassing them, which is often a last-resort. In giving such advice, I often start with something like this:

Firstly, before you subclass an object, you should ask yourself “do I need to do this?”

The general idea here is that people will often go out of their way to make life harder for themselves, in order to change some functionality of a class that could otherwise be done through interaction with the class in one line of code, simply because they do not know of a simpler way, or do not dedicate a bit of their time to find out a more efficient method.

I think that a key skill in any programmer’s life is when you develop a certain intuition for what seems to be right or wrong –  you come up with a solution to your problem which looks too verbose or complex for what you’re trying to achieve, and this sets alarm bells ringing. However, before this is the case (and even when you do develop this skill), it’s important to think about what you’re doing; if you are approaching the problem, do some light research into it and ensure that what you are doing is one of the best, most efficient and painless ways to do it.

Make sure that what you’re doing is for the right reasons, and not simply doing it to make it work.