Design challenge: Simplicity vs preferences

I think this is a pretty common scenario that we find ourselves continuously battling.

You start off with a nice, simple, easy to understand component. You feel pretty pleased with yourself.

A while later, someone comes along and asks for it to work slightly differently. Hey, no problem. We'll add a preference so you can choose between the default behaviour and this new behaviour.

Then that happens again. And again. And then the fourth time it's a preference that adds to a previous preference but with a slightly different scope and behaviour. In certain combinations, it no longer makes sense.

Then you try and change the original behaviour but doing that breaks how those preferences work. Well, you see where I'm going here.

I don't think the answer to this is to have no preferences — people want to make software work the way they want — but some things to consider before adding a preference:

• Do we really need it?
• Can we design it so it's useful to many people not just the person asking for it?
• How are people going to know the preference exists?

And then, after it's been shipped, a continual process of review to see if we can remove any preferences in the future. In order of increasing value:

• Bad code
• Good code
• Code that you have deleted
• Code that you never needed to write