Here's one rule-of-thumb that just occurred to me. If there is "prior art" for code, the onus is on the person reading the code to show that it is "complex", "u

Here's one rule-of-thumb that just occurred to me. If there is "prior art" for code, the onus is on the person reading the code to show that it is "complex", "unmaintainable", or "clever." If there is no prior art for code, the onus is on the person writing the code to show that it is "simple," "maintainable," and "straightforward." Taking parser combinators as an example, if you write some code with parser combinators, simply document your choice as usual and include a hyperlink to http://en.wikipedia.org/wiki/Parser_combinator http://en.wikipedia.org/wiki/Parser_combinator. If I read your code and think this is overëngineered, it's up to me to show a better way, I can't simply wave it off as being too hard. That doesn't mean it gets a free pass, it could be that parser combinators for a custom DSL are too complex, perhaps the same problem could have been solved with JSON or something, but the default should be to accept it since it's a technique that is explained "in the literature." On the other hand, if I roll my own complex code and I can't point to a reference for the technique, then it's up to me to make the case that it's simpler than the alternative. For an example, Benjamin Stein and I wrote #andand for Ruby. It's related to the maybe or option monads, but it doesn't take the standard form so I can't really document it with a hyperlink. The onus is on me to show that in Ruby, #andand is simpler than testing for null, using the null object pattern, or organizing code such that there are no unexpected nulls.