Sometimes are the comments greater, than the actual posts. I would like to reuse one of such comments and comment it as a new post (thanks to Frank W. Zammetti for the comment).

"Adam, I was one of the folks involved in that "large discussion", so no need to rehash my comments on that topic here... I will comment on the "fat client with local embedded db" thought."

Thank you - this topic is much more interesting, than the art of JavaDoc :-).

"I actually think, underneath it all, that we have the same basic philosophy, and you can of course correct me if I'm wrong, but based on what you've written I believe we're on the same page...

Any coding project should be designed and coded as simple as possible, and no simpler."

Absolutely - but the code should be maintainable as well. I would define maintainable, as "easy to understand by an average Java Developer"

"That's the maxim I always work by, and it has served me well. I frequently bump up against other architects I work with because they are thinking in terms of this pattern, that design concept, this abstraction and that model. I instead think in terms of what's *really* the underlying goal, and what's the simplest way I can pull that off? Once I have that answer, only *then* do I think about adding all the other typical complexities we all deal with every day."

Even more important - some architects forget, because of patterns and best practices, the customer and its requirements.

"Sometimes complexity is inevitable, no question. Some problems just don't *have* a particularly simple answer. Other times, complexity is actually desirable, usually in the name of needed flexibility. I have no problem with those ideas, I agree completely."

Yes, but we have to differentiate between the "core" complexity, which is caused by the requirements and the "infrastructural" complexity, whichis caused by the infrastructure and esotheric architects :-).

"But it's when people take a relatively simple problem and over-burden it with all sorts of ideas and techniques that they've heard about over time, all the while thinking they are creating an elegant architecture because it dutifully implements every advanced CS technique there is, it's at that point I believe they've lost their way."

Then, everything becomes configurable, mockable, replacable and dynamic. "Cool" stuff is not always a best practice...

"I've seen people creating factories for things that arguably didn't need a factory... I've seen people making all sorts of things singletons for no obvious reason... I've seen people go out of their way implementing all sorts of read-write locking code when simple synchronization would have sufficed... I've seen people create a 30-class-deep hierarchy *just in case* someone wanted to extend the code at any of those 20 points... I've seen people choose EJBs over simple REST-based remote procedure call methods because "EJBs are the way to go for distributed code"... I've seen people refactor code into 30 different methods, each 2-3 lines long, because it supposedly enhanced the readability of the code... I've seen people create DTOs for two fields of data... I've seen people choose this persistence library or that when basic JDBC and SQL would have more than done the job... and so on."

And what's about configuration and overuse of layering?

"I'm not saying any of that stuff is inherently bad, nor is it necessarily wrong in any particular case. All I'm saying is that if that kind of stuff is coming out of your initial design sessions, either:(a) you're designing something inherently very complex and the flexibility is required, or (b) you're *way* over-thinking things. If the answer is (a), then fine, so be it... but I've seen *way* too many cases where it's really (b), but the architects/developers only know how to think in terms of (a), which is a Very Bad Thing(tm), IMHO."

Yes, you have still to think during the development. Beyond that, you can only build maintainable software, in case you are understanding the target domain really well.

Then the code will become not only maintainable - but even elegant. Btw. I will discuss some of the topics during my talk at JavaONE as well.