10 ms·

I was trained in Java, but I never had to do any Big Enterprise Java coding. Can anyone summarize why and when this style of development began?

slashnull 12y ago
I was briefly exposed to this doctrine at school, so I hope dropping the following buzzwords help: POJO, Java Persistent API, Java Enterprise Beans, Gang of Four Design Patterns
patio11 12y ago
A combination of wasteful architecture astronomy and legitimate need to divvy up absolutely mammoth line-of-business applications among teams with hundreds of members operating for years with wildly varying skill levels, often on different subsystems from different physical locations, with billions of dollars on the line. You can't let the least senior programmer in the Melbourne office bring down the bank if he screws up with something, so instead you make it virtually impossible for him to touch anything than the single DAO which he is assigned to, and you can conclusively prove that changing that only affects the operation of the one report for the admin screen of a tier 3 analyst in the risk management group for trans-Pacific shipping insurance policies sold to US customers. The tradeoff is, historically, that you're going to have to hire a team of seven developers, three business analysts, and a project manager to do what is, honestly speaking, two decent engineers worth of work if they were working in e.g. Rails. This is a worthwhile tradeoff for many enterprises, as they care about risk much, much, much more than the salary bill. (I spent several years in the Big Freaking Enterprise Java Web Applications salt mines. These days I generally work in Rails, and vastly prefer it for aesthetic and productivity reasons, but I'm at least intellectually capable of appreciating the advantages that the Java stack is sold as bringing to users. You can certainly ship enterprise apps in Rails, too, but "the enterprise" has a process which works for shipping Java apps and applying the same development methodology to e.g. a Rails app would result in a highly effective gatling gun for shooting oneself in the foot.)
- userbinator 12y ago
  In other words, the bureaucracy of the code reflects the environment it was developed in.
  - joyofdata 12y ago
    In other words, organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations —M. Conway (http://en.wikipedia.org/wiki/Conway%27s_law http://en.wikipedia.org/wiki/Conway%27s_law)
- raverbashing 12y ago
  I wonder how did this evolve to be... I remember (vaguely) the beginnings of Java, but not how it did end up in Enterprise and why it was loved so much there.
  - toyg 12y ago
    Initially, it aimed at replacing C++ (which it mostly achieved, for LOB apps). The primary market for Sun has always been the enterprise, so it was a natural target. Then, when the web exploded, people found out that developing against a virtual machine could be safer and more predictable than developing against the operating system, so web-app servers were born. J2EE provided a certain degree of consistency, which other platforms did not have. As platforms evolved, they tried to generalise their use-cases, which introduced a number of abstractions and forced decoupling; and because Java2 lacked support for a lot of introspection/metaprogramming features, you had to explicitly cover a lot of cases, leading to interfaces multiplying. It didn't help that at the time, the "Pattern" movement was popularised and their tools (which are all about decoupling and introducing further levels of abstractions) became overused.
- ahmacleod 12y ago
  Thanks, that's what I was looking for.
- fsloth 12y ago

slashnull 12y ago

I was briefly exposed to this doctrine at school, so I hope dropping the following buzzwords help: POJO, Java Persistent API, Java Enterprise Beans, Gang of Four Design Patterns

patio11 12y ago

A combination of wasteful architecture astronomy and legitimate need to divvy up absolutely mammoth line-of-business applications among teams with hundreds of members operating for years with wildly varying skill levels, often on different subsystems from different physical locations, with billions of dollars on the line. You can't let the least senior programmer in the Melbourne office bring down the bank if he screws up with something, so instead you make it virtually impossible for him to touch anything than the single DAO which he is assigned to, and you can conclusively prove that changing that only affects the operation of the one report for the admin screen of a tier 3 analyst in the risk management group for trans-Pacific shipping insurance policies sold to US customers. The tradeoff is, historically, that you're going to have to hire a team of seven developers, three business analysts, and a project manager to do what is, honestly speaking, two decent engineers worth of work if they were working in e.g. Rails. This is a worthwhile tradeoff for many enterprises, as they care about risk much, much, much more than the salary bill. (I spent several years in the Big Freaking Enterprise Java Web Applications salt mines. These days I generally work in Rails, and vastly prefer it for aesthetic and productivity reasons, but I'm at least intellectually capable of appreciating the advantages that the Java stack is sold as bringing to users. You can certainly ship enterprise apps in Rails, too, but "the enterprise" has a process which works for shipping Java apps and applying the same development methodology to e.g. a Rails app would result in a highly effective gatling gun for shooting oneself in the foot.)

userbinator 12y ago
In other words, the bureaucracy of the code reflects the environment it was developed in.
- joyofdata 12y ago
  In other words, organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations —M. Conway (http://en.wikipedia.org/wiki/Conway%27s_law http://en.wikipedia.org/wiki/Conway%27s_law)
raverbashing 12y ago
I wonder how did this evolve to be... I remember (vaguely) the beginnings of Java, but not how it did end up in Enterprise and why it was loved so much there.
- toyg 12y ago
  Initially, it aimed at replacing C++ (which it mostly achieved, for LOB apps). The primary market for Sun has always been the enterprise, so it was a natural target. Then, when the web exploded, people found out that developing against a virtual machine could be safer and more predictable than developing against the operating system, so web-app servers were born. J2EE provided a certain degree of consistency, which other platforms did not have. As platforms evolved, they tried to generalise their use-cases, which introduced a number of abstractions and forced decoupling; and because Java2 lacked support for a lot of introspection/metaprogramming features, you had to explicitly cover a lot of cases, leading to interfaces multiplying. It didn't help that at the time, the "Pattern" movement was popularised and their tools (which are all about decoupling and introducing further levels of abstractions) became overused.
ahmacleod 12y ago
Thanks, that's what I was looking for.
fsloth 12y ago