5 ms·

I don't understand how anything on HN that discusses a more complex software architecture is immediately called J2EE/enterprisy and dismissed. Is this because

by adamors 12y ago

I don't understand how anything on HN that discusses a more complex software architecture is immediately called J2EE/enterprisy and dismissed. Is this because the majority of the community is self thought? Or is this because most of you only build MVPs which are mostly CRUD apps (and therefore don't know from first hand experience the benefits of a modular system)? The constant negative reaction to anything a little more complex is frankly laughable.

wfjackson 12y ago
If simple MVP CRUD apps are one end of the spectrum, then there is the other end which looks a bit like this: https://plus.google.com/+aerotwist/posts/1QhcnQizuPc https://plus.google.com/+aerotwist/posts/1QhcnQizuPc description: "Convenient proxy factory bean superclass for proxy factory beans that create only singletons." http://docs.spring.io/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html http://docs.spring.io/spring/docs/2.5.x/api/org/springframew...
- adamors 12y ago
  Of course you can overarchitect software. But there's also more discussion to be had on this subject other than "OMG looks like Java, OP sucks".
ChrisGaudreau 12y ago
It does get a little tiring when somebody tells you "you're doing it wrong. It has to be more abstract and complex because you might become the next Facebook." And then everything turns into a StrategySingletonProxyFactoryBeanFactory.
- sanderjd 12y ago
  It totally is. And the opposite is also really tiring. I feel like the silent majority are just trying to find a good middle path that works well with their specific applications, while the loud minority on both sides are yelling about how the other side is doing it wrong.
soAsian 12y ago
>Is this because the majority of the community is self thought? Or is this because most of you only build MVPs which are mostly CRUD apps (and therefore don't know from first hand experience the benefits of a modular system)? I had come to the same conclusion regarding Hacker News. It's like bunch of kids chasing the newest trend in fashion. Hey guys RoR is so cool. Check it out what it can do. As if people just find out what MVC pattern is and wow Scala what a great language. Hey guys let's all switch over to this new hottness then you check out what all these start ups is doing and it just another CRUD app or so call Email killer app. It's fun to watch these kids chasing the new hot trend like the fashion industry.
ubernostrum 12y ago
The examples in the OP, as in basically every article that describes these kinds of practices, are horribly contrived. The lighter-weight frameworks we have now in languages like Ruby and Python do have abstraction to deal with changing out bits of technology, but they've reached a point where they abstract only the things that experience has shown are likely to change, and support only the changes that are likely to happen. Nobody in the real world is suddenly going to decide to "persist" their employee records to volatile local memory instead of something permanent like a database. Introducing new layers of abstraction -- with the attendant increase in complexity and potential abstraction leak -- to support those types of contrived hypotheticals is how overabstracted systems like J2EE come to be.
- adamors 12y ago
  Correct me if I'm wrong, but one of the points of using dummy persistence is testing. You can delay using a database for a long time this way, have tests that finish quickly etc. Doing this within the confines of a Rails like MVC is next to impossible.
  - ubernostrum 12y ago
    I am also a strong non-fan of faking persistence mechanisms in testing. If you're faking it, you don't actually know that the real thing will work.
    - adamors 12y ago
      That's what functional tests are for. But if you're doing TDD there's no point in constantly running your functional/acceptance tests.
      - ubernostrum 12y ago
        Anything that's not full verification isn't verification at all :)
- ryanjshaw 12y ago
jdminhbg 12y ago
Similarly, any criticism of overcomplexity is immediately met with a dismissal as anti-intellectualism rather than a justification of why it's necessary. > Or is this because most of you only build MVPs which are mostly CRUD apps (and therefore don't know from first hand experience the benefits of a modular system)? This is what I use Rails for, and its entire reason for existing. It's a set of conventions for CRUD apps, not a general-purpose language for building distributed databases and coordinating space missions. The problem with these complex software architectures is that they're decoupling Rails from the database, but why in the world would you want to do that? Rails is great because it manages the the meeting point between web requests and relational databases in an elegant, repeatable, commonly-understood way. If you need a complex, general-purpose system that only sometimes will talk to a database for persistence, why in God's name did you use Rails?
- ryanjshaw 12y ago
  > Similarly, any criticism of overcomplexity Come on. Nobody is defending "overcomplexity", which is by definition a rather indefensible position. The issue is the frequent arrogance exhibited here by commenters who insist that certain commonly and successfully used design patterns have no place in the world.
  - jdminhbg 12y ago
    Of course I mean defending against the charge of overcomplexity rather than defending overcomplexity itself. I am sure there are arrogant commenters around, but these commonly used design patterns applied in this case have made his code worse for next to no practical benefit. Besides test speed, there's no reason you'd want to divorce your Employee model from the database it lives in -- the fact that ActiveRecord reflects against the database to decide what attributes an Employee has should be a clue that coupling to the DB is the point of using it in the first place.
  - jarrett 12y ago
    > who insist that certain commonly and successfully used design patterns have no place in the world. I don't think the architecture skeptics claim as much. I believe you're restating the claim in a more extreme way that it's commonly expressed, thus making it clearly indefensible. The claim isn't that certain architecture patterns have no place in the world. Rather, the claim is that those patterns aren't a good fit for most Rails apps. Pretty much any pattern (that's not a commonly-accepted antipattern) has some good use case, somewhere.
jarrett 12y ago
> I don't understand how anything on HN that discusses a more complex software architecture is immediately called J2EE/enterprisy and dismissed. I wouldn't say that always happens. It often happens when a 500-word blog post suggests effectively re-architecting a mature, successful framework like Rails. Let's think about why such a post is problematic. Rails has evolved over quite a few years in response to actual needs on the ground. Tremendous amounts of ink have been spilled, and tremendous amounts of brainpower have been expended to create a mature framework like Rails (or similar frameworks). Despite the battle-tested history of the framework, so many of these architecture blog posts imply that Rails' architecture is somehow insufficient. And then propose to fix that architecture, spending, say, 500 words explaining the idea. There's hardly any discussion of the idea's wide-ranging implications, of the trade-offs, or of the conveniences that are lost. If this idea is so good, why hasn't it ever found its way into Rails, even in diluted form? Why has the Rails team built the architecture they have, instead of yours? (Hint: They probably have a good reason.) Do you have strong evidence that your proposed architecture will serve me better than the one that I've been using successfully for years? All that being said, I have no problem with idiosyncratic Rails techniques that only step a little outside what the framework provides. For example, service objects. Used appropriately (which usually means sparingly), they can help with organization without fundamentally warping the Rails app. Using a few service objects is a departure similar in magnitude to writing your JS in TypeScript instead of CoffeeScript. It's not built into Rails, but it doesn't really change any of the core concepts either.

by adamors 12y ago

wfjackson 12y ago

If simple MVP CRUD apps are one end of the spectrum, then there is the other end which looks a bit like this: https://plus.google.com/+aerotwist/posts/1QhcnQizuPc https://plus.google.com/+aerotwist/posts/1QhcnQizuPc description: "Convenient proxy factory bean superclass for proxy factory beans that create only singletons." http://docs.spring.io/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html http://docs.spring.io/spring/docs/2.5.x/api/org/springframew...

adamors 12y ago
Of course you can overarchitect software. But there's also more discussion to be had on this subject other than "OMG looks like Java, OP sucks".

ChrisGaudreau 12y ago

It does get a little tiring when somebody tells you "you're doing it wrong. It has to be more abstract and complex because you might become the next Facebook." And then everything turns into a StrategySingletonProxyFactoryBeanFactory.

sanderjd 12y ago
It totally is. And the opposite is also really tiring. I feel like the silent majority are just trying to find a good middle path that works well with their specific applications, while the loud minority on both sides are yelling about how the other side is doing it wrong.

soAsian 12y ago

>Is this because the majority of the community is self thought? Or is this because most of you only build MVPs which are mostly CRUD apps (and therefore don't know from first hand experience the benefits of a modular system)? I had come to the same conclusion regarding Hacker News. It's like bunch of kids chasing the newest trend in fashion. Hey guys RoR is so cool. Check it out what it can do. As if people just find out what MVC pattern is and wow Scala what a great language. Hey guys let's all switch over to this new hottness then you check out what all these start ups is doing and it just another CRUD app or so call Email killer app. It's fun to watch these kids chasing the new hot trend like the fashion industry.

ubernostrum 12y ago

The examples in the OP, as in basically every article that describes these kinds of practices, are horribly contrived. The lighter-weight frameworks we have now in languages like Ruby and Python do have abstraction to deal with changing out bits of technology, but they've reached a point where they abstract only the things that experience has shown are likely to change, and support only the changes that are likely to happen. Nobody in the real world is suddenly going to decide to "persist" their employee records to volatile local memory instead of something permanent like a database. Introducing new layers of abstraction -- with the attendant increase in complexity and potential abstraction leak -- to support those types of contrived hypotheticals is how overabstracted systems like J2EE come to be.

adamors 12y ago
Correct me if I'm wrong, but one of the points of using dummy persistence is testing. You can delay using a database for a long time this way, have tests that finish quickly etc. Doing this within the confines of a Rails like MVC is next to impossible.
- ubernostrum 12y ago
  I am also a strong non-fan of faking persistence mechanisms in testing. If you're faking it, you don't actually know that the real thing will work.
  - adamors 12y ago
    That's what functional tests are for. But if you're doing TDD there's no point in constantly running your functional/acceptance tests.
    - ubernostrum 12y ago
      Anything that's not full verification isn't verification at all :)
ryanjshaw 12y ago

jdminhbg 12y ago

Similarly, any criticism of overcomplexity is immediately met with a dismissal as anti-intellectualism rather than a justification of why it's necessary. > Or is this because most of you only build MVPs which are mostly CRUD apps (and therefore don't know from first hand experience the benefits of a modular system)? This is what I use Rails for, and its entire reason for existing. It's a set of conventions for CRUD apps, not a general-purpose language for building distributed databases and coordinating space missions. The problem with these complex software architectures is that they're decoupling Rails from the database, but why in the world would you want to do that? Rails is great because it manages the the meeting point between web requests and relational databases in an elegant, repeatable, commonly-understood way. If you need a complex, general-purpose system that only sometimes will talk to a database for persistence, why in God's name did you use Rails?

ryanjshaw 12y ago
> Similarly, any criticism of overcomplexity Come on. Nobody is defending "overcomplexity", which is by definition a rather indefensible position. The issue is the frequent arrogance exhibited here by commenters who insist that certain commonly and successfully used design patterns have no place in the world.
- jdminhbg 12y ago
  Of course I mean defending against the charge of overcomplexity rather than defending overcomplexity itself. I am sure there are arrogant commenters around, but these commonly used design patterns applied in this case have made his code worse for next to no practical benefit. Besides test speed, there's no reason you'd want to divorce your Employee model from the database it lives in -- the fact that ActiveRecord reflects against the database to decide what attributes an Employee has should be a clue that coupling to the DB is the point of using it in the first place.
- jarrett 12y ago
  > who insist that certain commonly and successfully used design patterns have no place in the world. I don't think the architecture skeptics claim as much. I believe you're restating the claim in a more extreme way that it's commonly expressed, thus making it clearly indefensible. The claim isn't that certain architecture patterns have no place in the world. Rather, the claim is that those patterns aren't a good fit for most Rails apps. Pretty much any pattern (that's not a commonly-accepted antipattern) has some good use case, somewhere.

jarrett 12y ago

> I don't understand how anything on HN that discusses a more complex software architecture is immediately called J2EE/enterprisy and dismissed. I wouldn't say that always happens. It often happens when a 500-word blog post suggests effectively re-architecting a mature, successful framework like Rails. Let's think about why such a post is problematic. Rails has evolved over quite a few years in response to actual needs on the ground. Tremendous amounts of ink have been spilled, and tremendous amounts of brainpower have been expended to create a mature framework like Rails (or similar frameworks). Despite the battle-tested history of the framework, so many of these architecture blog posts imply that Rails' architecture is somehow insufficient. And then propose to fix that architecture, spending, say, 500 words explaining the idea. There's hardly any discussion of the idea's wide-ranging implications, of the trade-offs, or of the conveniences that are lost. If this idea is so good, why hasn't it ever found its way into Rails, even in diluted form? Why has the Rails team built the architecture they have, instead of yours? (Hint: They probably have a good reason.) Do you have strong evidence that your proposed architecture will serve me better than the one that I've been using successfully for years? All that being said, I have no problem with idiosyncratic Rails techniques that only step a little outside what the framework provides. For example, service objects. Used appropriately (which usually means sparingly), they can help with organization without fundamentally warping the Rails app. Using a few service objects is a departure similar in magnitude to writing your JS in TypeScript instead of CoffeeScript. It's not built into Rails, but it doesn't really change any of the core concepts either.