Tim Anderson comments on Matt Mullenweg’s disdain for the 40 or so pages of preferences in Open Office and asks:
I accept the main premise - software should just work. I understand the further implicit argument, that adding options may tends to diminish software quality, by adding complexity to the code. But it would be interesting to analyze some of the options in, say, Open Office, and find out why they are there and who is using them. Is having all these options tucked away really a bad thing, or this really more about user interface design?
My answer: Yes, because it makes QA harder. And since there’s never "enough" QA, anything which makes it harder will reduce quality.
If I have 10 options with two possible states each, then assuming at least some overlap in functionality of these options I now have 2^10 configurations to test for each test case (a generalization, but in the right ballpark).
Interestingly, though, I’m in a market which demands customization. This is essentially all of the QA headaches without the UI complexity. Customers pay us to adapt our (very configurable) software for them. So we still need to make sure it works, and we still have the code support for this customization, but the users don’t have to deal with 40 pages of "preferences."
{ 2 } Comments
With 10 options at two states apiece, you have 2^10 configurations to test, not 10^2. Each Boolean option you add doubles the number of configurations you can have.
Thanks, Rob; I did indeed write that backwards and I’ve fixed it now. I appreciate the correction.
Post a Comment