''Options are bad.'' I've seen that claim too many times now. Like often, the intention of such phrases is good, but is easy to mis-interpret. This is very similiar to ''KISS'': Of course it is important to keep things simple, and often even force yourself to keep your project simpler than it could be - since else you will need to spend increasinly more time. But the things which you want need to be there nevertheless - the most simple program always is no program at all, and that is not the goal of KISS. Also, projects do evolve over time, and so a feature which initially would have violated KISS might very well be possible a year later. With options, more options not only violate the KISS principle, but also the amount of testing increases. Still, options are not bad. That is - if you allow adjusting any small setting, then yes, this may be bad - many combinations might not make sense, and things get complicated, if not in code then for the user who can not know which settings make sense and which not. But, if you have no options, you actually do have options - they simply are fixed and forced on the user, without the possibility to choose what they like. Which is very bad. And, the claim that testing increases much is false, if you do options right. The example that may be given is, if you have 4 boolean options A, B, C and D, then you need to test your program with ABCD first, then ABC[D], AB[C]D, AB[C][D] and so on, 16 possible combinations in total. But that assumes that each option depends on all the other ones. If your options behave like that, they probably are done in a bad way. Good option are done so they automatically work together with any other options. This is not always simple to achieve of course. So yes, no options is simpler than options. Such as no program is simpler than a program. But a program with good options is much better than a program with no options. Since, at least for part of the users, the hardcoded defaults will be bad defaults.