"A while ago I was asked what I think was a good quality for an architect. My reply was that he should set things up in such a way where the developers are bored.
That may sound... harsh to some, but I believe that we have enough complexity in our applications as it is. A success story is reducing the complexity to such a level that we focus on the business value, rather on the technical difficulties"
After thinking about it a while I realized that this is exactly what I aim for in my projects. I'm trying to maximize the time my developers spend on writing compiled code solving business logic. Practicing Domain Driven Design and TDD using NHibernate, MVC, Windsor, Rhino Mocks etc. tend to keep the developers writing "boring little C# classes" where nested foreach loops are "as complex as it gets". So when you hear words like, "Please can't we put in some multithreading here I'm so bored..." you know you have a great design!
So how are you going to bore developers without them being bored?
I think the key is to make people understand why it's good to spend so much time writing those little boring classes. And then ease the need for complexity by involving them in the continuous effort to improve and evolve the architecture, design, tooling, processes etc. that enables the team to spend even more time with "boring" things.