Yep, really the disease is taking ANY such rule or heuristic and interpreting it to be valid in all situations or in an extreme form.

The last paragraph is the simplest and most effective solution - start asking specific (well defined) questions about your system (not all systems or some other bloggers) and suddenly there is no need for any of these bullshit heuristics. I love this approach, its the heart of engineering right here.

Of course, there really is something special about 0, 1, and Inf -- they're the kind of numbers that tend to arise from theory, not just from tuning. Tuning is hugely important for real systems, so an allergy to 'arbitrary' numbers is not useful; on the other hand, this rule is often a nice heuristic to keep in mind when you're picking which numbers to expose in your config files.

As I understand it, "Zero, one, infinity" is not about what numbers should be coded, it is about what numbers should be hard-coded. The concept is that if you have a number other than one of those three, then as the author says it is most likely a number derived from intuition, limits, or current requirements. All of these can easily change over time, even the value of PI, which might need to be made more or less precise, or the columns of a sudoku when someone wants to create a 1-16 challenge sudoku. Thus, all of these numbers not derived from theory but from tuning should be soft-coded into variables and placed in one location so they can be easily changed if needed.

By odd coincidence, tomorrow I'm recording the first episode of a podcast called 'Zero, One, Infinity', so this was a bit weird to see today. If it had been posted in a couple of days, I think I would have assumed from the title it was a bad review ;-)