adam bien's blog

 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, which
is 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.