Settings

As a developer, I think a lot about settings. Not just settings, but approaches; ways of solving problems. Ultimately, everything comes down to style on some level, and while I don’t believe that there’s a right answer and a wrong answer to every problem, I do think that there’s always a better answer.

One thing I hear a lot from people is “why not just make it optional?” It’s a fair question, and I understand why they gravitate towards it. The developer has one opinion, a customer has another, so it makes sense that adding an option to have it both ways is an easy out.

The problem is, it’s absolutely the wrong question. The real question is “how did we get here?” If you step back, look at the root of the problem and not just the symptom, you’ll usually find that there’s a better approach to the whole thing that makes the idea of a setting completely obsolete. Everyone can argue about how to put a bandage over a wound, but few people step back and think about preventing those wounds in the first place.

Simply put: settings are usually excuses for bad design.

Of course, there are genuine situations where there really are as many people who want something one way as there are who want it the other. Those are the times when settings make sense, but all too often developers try to fix the symptoms rather than tackle the underlying problems (*cough* Windows). It’s hard—really hard—but there’s almost always a better way. I may not make my customers happy in the short term when I tell them that I’m not going to add a setting for (fill in the blank here), but by refusing to put a bandage on the wound, I keep the pressure on myself to make a better app in the long run by simplifying, re-thinking, and evolving.