Fat Clients, Effcient Architectures - (re)feedback, or why cool stuff is not always a best practice
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). 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.
"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
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
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."
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).
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.