Kevin Barnes examines needless complexity - it's a good article, and you should read the whole thing. This paragraph is worth looking at by itself though. Too many people see (insert currently fashionable language here) as the answer to everything. Kevin responds:

The point is that we need to be willing to take risks if we are going to do the best job possible.  I've seen more complexity leaked just because people assumed that the generally accepted norm was correct than for any other reason.  Don't be afraid to break the rules if it makes sense.  Write your code in Smalltalk or Lisp if it looks like the best way to solve your problem.  Use Perl or Python or JavaScript code.  Write to a file rather than a database.  Remember that the problem you are facing and the solution you will provide are real and not an academic exercise.  Choosing a non-status-quo solution implies that you have taken the time to understand the repercussions of that decision and that you will not be leaking complexity (installation complexity, code complexity, licensing complexity), but otherwise don't stand on custom.  Properly containing the problem is the most important aspect.  On the flip side, don't just be an iconoclast to be an iconoclast.  The decision must always be about the problem and not just an arbitrary expression of personality.