Occam’s razor. Now all new and improved in the digital age.

Dare Obasanjo’s blogged about the danger of complex solutions and the benefits of duck-tape programming.

Indeed, this philosophy can be applied outside the programming world, but since I’m responding to this specifically I’ll continue to use the software context.

I don’t agree. Of course I acknowledge that in order to get software out the door, sometimes you have to scale back on feature creep and can’t always satisfy all concerns on version one. Very often by seeing your software being used you find that all the concerns you had thought to satisfy originally aren’t real concerns. What I disagree with is the mantra that ‘Simpler is always better’. I prefer the Occam’s razor version : ‘Keep things as simple as possible, but no simpler’.  It’s ironic that this is easier to understand than the literal translation “Don’t multiply entities unnecessarily”. 🙂

It’s easy to find examples to counter the WWW/Xanadu example that Dare points out. In fact a surprising number of them come from Google. A notable one is Gmail. I was a hotmail user and liked the benefits of a web client. Gmail was late to the game, but they brought with their client significantly more complexity. Namely, threaded conversation view, tagging of emails instead of folders (and the inbox tag, for archiving), and a thick javascript client that would take longer to load initially, but user experience once logged in would be super quick. Coupled with the incentive of significantly more space which was actually eventually matched by hotmail at the time I switched, the added complexity/functionality was a boon for the user. Even as I show off the features of my gmail client to users of MSNLive and Yahoo, they grimace to think that all their organizing of their mail would be lost if they were to switch, the plight that can come from early adoption, coupled with a fear of the unknown.

More examples from Google: GWT, a more complex and yet surprisingly powerful way to write javascript, without more simply hacking away at native JS. And Google Wave, a potentially incredibly powerful and more complex way of merging chat, document editing and email into one. Of course it’s usefulness has yet to be proven at the time of writing. Inevitably Google Wave has already been under attack by the same people that live in the ‘Simpler is always better’ camp.

Of course duck-tape programming is often inevitable. Working in software, I often choose a duck-tape solution knowing full and well that it won’t scale simply because I don’t have the confidence in management to back me up were I to suggest the more complex solution. Complexity needs more time and educating to implement. I view this as not my problem because I know I probably won’t be around when it finally fails and it’s not worth the career risk to vouch for the better solution. It’s great when you do work under projects where you know that management has the foresight to stick with the better/disruptive solution even if that means coming at loggerheads with clients for a while. It’s incredibly dismaying to occasionaly see the hacky solution being chosen even when the better solution would take the same amount of time to implement, but is simply harder to think through.

I feel that an article favouring simplicity doesn’t do justice to the problem because sometimes the more complex solution is better. A more mature take would be to advise programmers to strike the right balance. Of course this is particularly hard advice to give and I fear I have no more generalized rules to offer than say look at all cases on a case by case basis. This would be a worthwhile area of research.