Every piece of code or bit of functionality you write has a cost of ownership to your business.
Every preference requires more testing to make sure that other things don't break as a result of a user changing an obscure setting.
If you don't mind having to write test cases for thousands of permutations of possible settings, go ahead and let your customer change everything. A simple product, however, is far easier to maintain.
To take a concrete example, we don't exactly enjoy maintaining justin.tv in many different languages. As a matter of fact the whole translations system adds a lot of complexity to the codebase. But we'd be bloody idiots to have the website exist only in English. Many other settings are similarly important.
If you don't mind having to write test cases for thousands
of permutations of possible settings, go ahead and let
your customer change everything. A simple product,
however, is far easier to maintain.
Obviously it's not a black and white issue... at some point if you provide enough options, you've probably provided a turing complete DSL. And that's not what I'm advocating. I'm advocating making things configurable "within reason" where I'll freely concede that "within reason" is a subjective measure.
And you're right about the cost, so you have to weigh that cost against the potential lost sales from not providing a given option. And you never know for 100% sure, especially since people who don't buy your product don't typically call you up and say "Hey, I didn't buy your stuff and here's why." "Silent evidence" as it were. So it's still a bit of a judgment call. I just come down on the side of being a bit more accepting of options and configurable items, than what I think the parent article is advocating.
Obviously, the simpler the product is, the easier it is to maintain. But as the product gets simpler and simpler, it becomes valuable to an ever-smaller pool of users, all of whom have differing needs. Obviously it's not as simple as "just build it simple." There's a delicate equilibrium that must be maintained.
While they're often linked, it's important to remember the distinction between "Simple Codebase" and "Simple to Use". The latter is much more important in most cases than the first, and sometimes it can take very complex code to make something as simple as possible for the user.
The simpler something to use, the bigger the pool. The fewer the applicable use cases, the smaller the pool.
You do mind but if the customer insists you have no choice.
My customers use metres, feet and statute feet, they work in degrees, deg/min/sec and grads. They work in X,Y,Z or N,E,Z (don't get me started on South Africa)
Then you have day/month/year and month/day/year, then you have Canadians that work in both.
It's easy for a web 2.0 site with no actual customers.
A Google search for "n e z coordinates" revealed that N stands for north or northings, E stands for east or eastings. Basically, it looks like they just swap X and Y.
Every preference requires more testing to make sure that other things don't break as a result of a user changing an obscure setting.
If you don't mind having to write test cases for thousands of permutations of possible settings, go ahead and let your customer change everything. A simple product, however, is far easier to maintain.