I’ve never done any J2EE programming. However, I have written business-critical code. I’ve written my fair share of LAMP code, and I’ve written enough Java code to last me the rest of my life. It’s no secret that I prefer Perl to Java for web development (and just about everything else).
I appreciate that addressing practical problems allows thoughtful developers to identify common problems and extract patterns and convenient abstractions to make solving similar problems easier in the future. I expect a mature language and platform to allow and encourage that.
In Defense of J2EE’s Complexity illustrates that idea, to some degree, in the evolution of the current best-practice J2EE tools. However, read the last paragraph:
… If you reduce complexity to a level that BOZOs start to contribute, you end up with even more serious problems. Any one whose had to maintain a VB application would vouch for me here. Software engineering needs to have a certain barrier to entry to keep BOZOs out.
I really don’t mind saving my brainpower for the difficult tasks, and I have much trouble seeing how someone not smart, or dedicated, or masochistic enough to slog through everything required to set up a productive J2EE environment diminshes the people who do.
Perceived elitism is a terrible justification for unnecessary complexity.
That is very lame.
I have experienced that many 'enterprise' developers don't think critically about introducing complexity into their applications. They believe that enterprise apps are inherently complex and therefore require complex solutions from the start. I was a J2EE developer for about 5 years (since EJB 1.1 in 2000) and experienced that phenomenon on a daily basis. I was even guilty of it myself, until I learned better. Judging by the comment you quoted I am sure the author is of that mindset.
I recall siting in meetings where ideas were shot down because they wouldn't scale, perform, or whatever, without any proof (prototyping or testing). The answer was always a big complex framework. In the corporate world, where J2EE is most often used, I think the bigger-is-better mentality rules. The cynic in me feels this way people can justify their big J2EE salaries.
Good apps should start simple. Only after simple solutions have been outgrown or proven not to fit should more complex solutions be used.
Well I must say that is a humorously typical but it is not really accurate (as usual).
The oft referred to 'complex coding security blanket' is really more paradoxical than anything else. It essentially veils the true problems facing organizations that use 'big/complex' software... and that's providing technical agility for their Users... i.e. speedy implementation of necessary capabilities, modifications, etc.
I've seen way-to-many examples of 10-12 person code teams (J2EE/.Net(vX))producing half the capability of other smaller teams using less framework oriented architectures (Perl/PHP). The paradoxical part also comes from programming teams hiding behind some ridiculously ineffective 'enterprise' production process model stuck using a framework that changes too often (.Net) or not often enough (J2EE).
Capability and technical agility is for clients/users; not programmers... yes, whether that user is a bus driver or a pilot.
The Hammer analogy is the best (and most humorously accurate) analogy of Enterprise/J2EE is here... http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12
What were the problems all that stuff mentioned in link was created for? I don't just get it, it seems like java would have contained those lacks and instead of fixing java they introduce all kind of complex trash to save the day! "Yaaay complex is so good!" I do not understand java guys but I guess nobody else does so it doesn't bother me. :-) About blogic, this came to my mind: http://aistigave.hit.bg/Logistics/
Basics of messing up everything: see problem x, be uncapable to fix x, do thing y to patch the problem x which contains problem z, see problem z, do thing a to patch the problem z which contains problem w, recurse until thing is so damn complex that you are the only one who understands it.
Thought, many amateur programmers rather see the problem and, instead of introducing complexity, fix it or find somebody who knows how to fix it. Are we just smarter since we understand this or do you professionals have some real reason to introduce the seemingly unnecessary complexity we non-professionals are able to avoid?
I completely agree. I really don't understand the "Easy == Bad" equation that seems to permeate through a lot of our society.
We produce PHP software that's used in the Enterprise, and often have to explain how just because PHP is popular and easy to get to grips with, it doesn't mean that it's basic.
I suppose it's the same kind of elitism that thinks that because the Spiderman movie is a hollywood blockbuster, it can't possibly be worthwhile, or that Nintendo platformers aren't worthy because they don't require three keyboards to control.
The advertisement for Java is scalable and enterprise. For me, Scalable means we can extend the app later to larger environment. Enterprise means applying for business, manufacturing, banking and sales environment.
J2EE means Java 2 Enterprise Edition. How many Editions Java has? And what is different between Java editions? Can someone in forum help me with
these questions?
After spending 4 years with an excellent startup ( http://www.precissystems.com/ ) where 4 of us developed and maintained 60 websites and 4 distinct e-commerce platforms (ASP & LAMP), I have moved on to do some contracting at another company.
This new company uses BEA WebLogic Portal to run their 3 websites - and it takes 40 people to do it. The Portal offers no content management, so we end up just editing HTML files on disk and FTP-ing them up to the production servers. We use IBM Rational ClearCase instead of CVS. A simple change to the menu (a capitalization error) took 2 experienced WebLogic engineers 3 weeks to complete because the system is so over-complicated and bloated.
Every week the "dev/test" database gets refreshed and the test servers suddenly cannot connect to it, they lose their JMS connections and basically fail. It takes 4 reboots (of the OS) before they come back online.
As a contractor I can laugh about the situation. Fortunately the websites are not mission-critical, just some basic info for consumers but no e-commerce or anything. Why they used WebLogic I will never know. I have done much more functional sites with much fewer resources, money, time, etc that could be managed by one person easily.
If it is this much of a pain just for the most simple website, I can only imagine what a mess a "real" web application would be if it were developed on BEA WebLogic. Of course, in its defense, it may have just been a poor implementation by engineers who didn't know what they were doing. Engineers who were still able to convince management to spend millions of dollars to get...this.
I would post a link but I don't want my contract to go away :)
Ha! It doesn't seem to have worked then, eh?
First I no nothing about J2EE, I have programmid in JavaScript, PERL, C, FORTRAN, APL, BASIC, bash, assembly, and I am just starting PHP. And over the years looked at FORTH, COBAL, SNOBAL, ALGOL. Some how I don't think I am a BOZO ;-)
OK then... if you follow the logic that it should be complex then I guess we should all start programming in INTERCAL. (don't get me started on the implications that logics has for Operating Systems) INTERCAL would make you think about what you are doing really hard so you would wright better programmers. S L O W E R . . .
http://catb.org/esr/intercal/
Take a look at any programming language and think about what that language was made for FORTRAN, COBAL, Bash, etc... all have there place. Why b/c you can develop programs faster for with a language that is made for a task then with a complex language the is all encompassing.
The quote reminds me of the argument in the 1980s about 'Complex Instruction Set' vs. 'Reduced Instruction Set' Computing. RISC won, yes it's faster over all but programmers were not using the Complex instructions provided on the processors ether.
PS the Military has learned the (New & Complex <> Good) or KISS quote from Todd Siegel "Only after simple solutions have been outgrown of proven, should more complex solutions be used." Is almost the motto of the Military and for a good reason.