Maximizers, Satisficers and Programming Languages

Whilst ambling around on the web after seeing a post on reddit.com that piqued my curiousity, I happened on some work discussing “maximizers and satisficers”, which, put crudely, says that there are two kinds of people. Those who, out of a group of options want the best one – maximizers – and those who just want something that will work – satisficers.

Anyone who has been around programming languages more than, say, a week, will instantly recognize the above theme in the endless discussions of “which programming language is best?”, or more generally, which “X” is best? I’d be willing to bet that programmers, and especially open source programmers, tend towards the ‘maximizers’ end of the spectrum – I don’t want just any old X, I want the best one, dammit! Sometimes, this can be a good thing, as it leads us to continuously seek to improve things we come into contact with, or try new approaches, it can also be detrimental if your goal is simply to accomplish some task, rather than spending too much time fretting about finding the perfect tools to accomplish the task with.

This also has ramifications for people designing or dealing with programming languages. One of the papers (the original?) on the subject (here), actually deals with the fact that maximizers, in their search for perfection tend to be less happy. Where satisficers are happy because they’ve got something that works, and they can go on to something else, maximizers have lots of room for “fear, uncertainty, and doubt” about their choices.

In some instances, actually reducing people’s choices makes them happier. Python’s “one good way to do it” makes everyone happy, because both maximizers and satisficers know that they’re doing things right, and don’t have room to worry. Another example that I know well from my involvement in the Tcl community is “object systems for Tcl”. For those who don’t know Tcl well, it’s an extremely flexible, extensible language, both in the language itself and in terms of its C API. So flexible, in fact, that you can write an OO system in Tcl itself, which has been done, or in C, which has also been done several times, leading to a proliferation of OO systems, and a never-ending stream of questions on the newsgroup about which is the best one? Perl’s “there’s more than one way to do it”, despite apparently providing and pushing choice, may actually work well because it encourages people to be satisficers and use whatever works. I’m sure everyone can think of examples where too much choice causes doubts and hesitation.

I think the lesson to be learned is that while it’s important to encourage experimentation in order to explore possible solutions to problems, at a certain point it makes sense to consolidate and provide one or two recommended ways of doing something. That’s not always possible (Linux distributions, for instance), and squashing competing ideas too early might cause friction with people generating innovation, so it can be difficult to accomplish, but I believe it’s an important social aspect of software creation to keep in mind.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s