Opinionated Software and the Paradox of Choice

In my last post I briefly mentioned the Paradox of Choice.

The alert amongst you will have noticed a lot of unapologetic talk about Opinionated Software recently out in the blogosphere.

Anyway it got me wondering whether the two are in some way related.

If people don't really like a choice, especially one they don't feel educated enough to make, then software that makes the 'right way' easy and the other ways hard or impossible, is bound to be popular isn't it?

Seems reasonable to me.

What do you think?

Comments

• Anonymous
  December 18, 2008
  PingBack from http://blog.a-foton.ru/index.php/2008/12/19/opinionated-software-and-the-paradox-of-choice/
• Anonymous
  December 18, 2008
  I've have been carrying around 'Paradox of Choice' in my messenger bag for a few weeks. I really want to get to it...I think the Opinionated Software piece is contradictory, at least how it is written. I think it is a good if you are part of a company that is creating an application that will be a product, with a purpose, a vision and a target population. I don't think you could really say the same for a consultant or employee that is writing an application for use within a company where it will not be a product, the purpose is not quite clear, the vision is not quite defined and the target population might be entirely different than originally planned.The problem if you take the opinionated approach in that case is, what you have envisioned as the purpose and intent of your solution may not be the solution at all if you do not understand enough about what you are trying to solve. 'You're either on the bus or off the bus.' can't work if you are writing an in-house application. The developer has limited insight into the business problem and more than likely does not know why the problem exists or what underlying problem is really trying to be solved. It seems somewhat arrogant to build something with a 'my vision is the right vision' approach and over-architect. I think you should try to solve the problem by simplifying the problem (with continued clarification of what the heck you are building) and the solution. It is far easier to go back and add additional considerations into your solution than it is to find you built something that is complex, narrow-scoped in what it does and has to be re-written anyway.I think eliminating choice can be a good thing, but also think about the situations where there is a company somewhere that has a department that takes some exported data file from some mainframe system where an employee has to run that data file through 8 different small applications to convert data because the developer lacked the foresight to determine the actual problem and just developed what he or she thought was the way to do something...