''And here's one for you. Give one careful example of two implementations of the same thing, ''
'''meeting the same quality criteria'''
'', where the more complex implementation is better. --RonJeffries''
-----
This is a misleading request.  "Better", above, is not defined with respect to what quality is sought.  So each participant in the discussion wins by their own definition of what they find better about their preferred solution.  Further, "simpler" and "complex" are not defined, in the same way.  

''The invitation is to make up your own criteria of quality. Please leave out ComplexIsBetter as one of them. Include performance, if you want to. Then write two implementations that meet your criteria. Explain why the complex one is better by your own standards.''

Further, even normalizing all of the above, it is typically the case that whatever one thinks up is the "simplest" and "best" they can find, because that is what they have thought of so far.  

''This is quite true. That's why we recommend PairProgramming, and it's why the PropellerBeanie is in fact not an evil thing. It is a friendly way for a colleague to suggest that one hasn't yet thought of the simplest/best idea. Saying the words invites the original author to defend. Offering the Beanie invites him to think, or to ask, "I guess you have a simpler idea?" It tends to get the conversation off on the right foot. YMMV, don't use a Beanie if you don't want to. But DO find a way for colleagues to help you find simplicity where you didn't find it the first time.''
-----
Bubble Sort is by far the simplest.  Shell Sort, Merge Sort, and all the others are way more complex.  But used standardly, for good reason.  

''Yes. But if you and I are personally going to implement a sort routine, I'll wager a lot that I can implement a bubble sort before you can implement shell. And up to around a thousand elements a thousand times, the difference in performance will not be noticeable.''

''So if you are marketing a sort routine, consider writing a complex sort algorithm. If you are writing a report program showing an average of 60 records, either use any existing sort routine, or write a very simple one. Anything else will waste your customer's money. --RonJeffries''
-----
Denormalized databases are more complex than normalized.  I have yet to meet a DBA who implements the normalized structure on disk - it typically does not meet performance needs.  So they denormalize, knowing that makes things more complex.  In this situation ComplexIsBetter.

''Yes, certainly performance, ''
'''measured, '''
''is often a valid reason for adding complexity. It is not, IMO, a valid reason for adding complexity before a performance measure shows the optimization is really needed.  The wise designer of a relational database designs normalized, then denormalizes when performance requires. The unwise designer unnormalizes early and pays the penalty in more difficult migration and more costly updates. --RonJeffries''
--
Of course, Insertion Sort is simpler conceptually and algorithmically than Bubble Sort, at the same speed...