Jeff Cunningham: The ridiculous Java bashing needs to stop

Discussions

News: Jeff Cunningham: The ridiculous Java bashing needs to stop

  1. Jeff Cunningham has posted "The ridiculous Java bashing needs to stop," addressing some of the claims made by people advocating Ruby, who compare Rails to various Java architectures and speak of Ruby's speed and ease of development. The claims, he says, are exaggerated. He brings up three points: the first point is that Java doesn't require extra tiers for application development, and in the case that extra tiers are chosen, are they really that much of a problem?
    Our app has 4 basic layers which i think are common for the current ideas of java development: Model, data access layer, action layer, and the view. In fact, if you use Annotations and JPA, your model and data access layer can be combined, similiar to Active Record. Then you have the same 3 simple layers Rails has. However, even if you have the 4th layer, for us its iBatis, how much extra work is it really? At least for us, very little. Taking the extra 5-10 minutes to add some SQL to an xml file isnt exactly pushing our development schedule out by 6 months.
    The second point is about Java compile time. He says that compile time really isn't much of a factor at all, if you're compiling changes to your codebase rather than recompiling an entire large codebase at one time. Compiling changes-only is a very common practice, and it's implemented by default in Eclipse-based IDEs; Even javac won't recompile classes unless it can determine that the class' dependencies have changed. [Editor's note: Anecdotally, I have a sizable project that does a clean build in seven seconds on a fairly underpowered system by today's standards, which doesn't really interrupt my personal flow at all.]
    If you work in small cycles like most developers probably do, does the 10 second compile time really bring your brain and development momentum to a halt? Come on...if you are making changes in small chunks (i.e. not modifying 100 files at once without testing your code), then this argument is bogus. The day that the extra 5-10 seconds it takes to run the Compile task in my build.xml file throws off my development hot streak (sarcasm) is the day i need to find a new job.
    The third point is about hot deploy:
    The HUGE (more sarcasm) time it takes to recycle your changes on the webserver to test your changes. I can buy this argument if you are running on a heavy appserver, but we use relatively simple tomcat for development (and production).
    This point is a little harder to accept, using Mr. Cunningham's benchmark of 10-20 seconds for a complete recycle of the application deployment. It'd be interesting to see how long the average redeployment takes, and on which application servers. What do you think? Is the constant comparison of Rails to Java a "scare tactic" or does it have merit? If it has merit, should Java EE do more to address its weaknesses in comparison to Rails?

    Threaded Messages (70)

  2. I agree that most of the arguments to support RoR can be questionable. RoR has a very simplistic approach to web applications and surely there is a number of those who can benefit from it. However, there are also a high number of scenarios in which I believe RoR falls short. That said, competition can only be good. J2EE-RoR comparison is not FUD and will surely push java in a direction where simple applications (hopefully) will have simpler solutions - I think that most people agrees that many J2EE specs are overkill for average Joe's CRUD.
  3. I agree that most of the arguments to support RoR can be questionable. RoR has a very simplistic approach to web applications and surely there is a number of those who can benefit from it. However, there are also a high number of scenarios in which I believe RoR falls short.
    That said, competition can only be good. J2EE-RoR comparison is not FUD and will surely push java in a direction where simple applications (hopefully) will have simpler solutions - I think that most people agrees that many J2EE specs are overkill for average Joe's CRUD.
    iyinet webmaster forumu 2008 seo yarışması this is my website visit it!
  4. Of course[ Go to top ]

    Java solutions should constantly keep getting better. The lack of -zero- turn around time is a big impediment for many development styles, especially when involved in design and prototyping. People sometimes, reasonably, want to change some code, hit reload in their browser, see the change immediately, and continue tweaking as required. Java is not just being compared to the fashionable RoR, it's also being compared to languages like PHP, which despite (in the case of PHP) being a dog's breakfast often yielding unmanageable code bases, can be much easier to set up and work with, even compared to RoR, and are trying to move into Java's "enterprise" space (see Zend &c's recent efforts).
  5. Re: Of course[ Go to top ]

    Wrt instant code compile / browser refresh of changes - some people are fighting the good fight to get java web development more on par with dynamic languages. Howard has a similar instant class reload setup in the new Tapestry version being worked on....If more frameworks work to address the simple (but hard to implement) things like this it might make for a better java argument. http://tapestry.apache.org/tapestry5/
    Java solutions should constantly keep getting better. The lack of -zero- turn around time is a big impediment for many development styles, especially when involved in design and prototyping. People sometimes, reasonably, want to change some code, hit reload in their browser, see the change immediately, and continue tweaking as required.

    Java is not just being compared to the fashionable RoR, it's also being compared to languages like PHP, which despite (in the case of PHP) being a dog's breakfast often yielding unmanageable code bases, can be much easier to set up and work with, even compared to RoR, and are trying to move into Java's "enterprise" space (see Zend &c's recent efforts).
  6. Re: Of course[ Go to top ]

    Look no further: http://grails.org Regards, Dmitriy.
    Java solutions should constantly keep getting better. The lack of -zero- turn around time is a big impediment for many development styles, especially when involved in design and prototyping. People sometimes, reasonably, want to change some code, hit reload in their browser, see the change immediately, and continue tweaking as required.

    Java is not just being compared to the fashionable RoR, it's also being compared to languages like PHP, which despite (in the case of PHP) being a dog's breakfast often yielding unmanageable code bases, can be much easier to set up and work with, even compared to RoR, and are trying to move into Java's "enterprise" space (see Zend &c's recent efforts).
  7. Re: Of course - yay groovy.[ Go to top ]

    Grails, heck look at Groovy period. I'm back on the Groovy booster side now that 1.0 has been released and there are good books/websites for it. Grails could possibly insulate Java from the RoR argument. It has some significant advantages: - Groovy is easy for Java developers to pick up (although it may take a bit longer to master some of the cooler features) - Groovy code has direct access to all of the Java API and the huge amounts of 3rd party libraries. Ruby, does not have nearly this amount of support yet. - Groovy compiles down to ordinary bytecode so it benefits from all the high-tech JVM enchancements and on the fly compiling. - Java projects using Groovy (e.g. Grails) can run on industry and time-tested application containers (tomcat, websphere, jboss, etc). This is a big plus for java developers since they can reuse their significant time invested in learning J2EE security, JNDI, JMX, app server setup/configuration, etc. - Java on a properly setup container is stable as hell and easy to scale. - Java 1.6 makes integrating Groovy (and other scripting languages) easier and more standard. - Since Groovy is a Sun standard it is much easier to get it accepted into corporate environments. Ruby is a resell of an entire stack. - You probably don't have to look for Groovy developers. It would be just as easy to retrain your good Java developers and have them bring along their J2EE experience. I don't worry about RoR that much. Ruby is a pretty cool language but Groovy matches its features. To my eyes Ruby is slightly better looking code but Groovy opted for sticking close to established Java conventions, which was the right choice IMHO. I'd love to do a Ruby project but right now I'm more excited about mixing Java and Groovy. It is nice to actually be excited a bit about Java development. Of course I do ActionScript 3/Flex too if I need to go totally off the rails....
  8. Re: Of course - yay groovy.[ Go to top ]

    I agree with almost everything in your post but this... "To my eyes Ruby is slightly better looking code but Groovy opted for sticking close to established Java conventions, which was the right choice IMHO." Really? I find most Groovy code far more readable and expressive than Ruby.
  9. Re: Of course - yay groovy.[ Go to top ]

    I agree with almost everything in your post but this...

    "To my eyes Ruby is slightly better looking code but Groovy opted for sticking close to established Java conventions, which was the right choice IMHO."

    Really? I find most Groovy code far more readable and expressive than Ruby.
    Yeah, I wouldn't say "far more" either way. It is just a difference. I'd bet that Java developers will prefer Groovy's look just because it is more in line with what they are used to. I find most of the Groovy warts are a side effect of its biggest benefit: tight integration with Java and the JVM. When Groovy looks less-than-slick it is usually when you are using an existing Java API. Again, none of this is important, just nit-picking.
  10. Re: Of course[ Go to top ]

    The lack of -zero- turn around time is a big impediment for many development styles, ... People sometimes, reasonably, want to change some code, hit reload in their browser, see the change immediately, and continue tweaking as required.
    You can do that with Resin since version 1.0. So it's an implementation limitation not the fault of Java or J2EE
  11. Re: Of course[ Go to top ]

    The lack of -zero- turn around time is a big impediment for many development styles, ... People sometimes, reasonably, want to change some code, hit reload in their browser, see the change immediately, and continue tweaking as required.


    You can do that with Resin since version 1.0.

    So it's an implementation limitation not the fault of Java or J2EE
    I think this statement is incorrect. I believe 'hot-swapping' is an outstanding Java feature planned forn a future JSR (JSR292). I do not know the specifics of resin, but I'd guess that it can only deal with 'hot-swap' changes that do not change the 'shape' of classes without having to do a full redeploy. It all comes down to classloaders I believe. The bottom line is that Java is not dynamic, and instant feedback in the form of REPL has been available in Lisp since 1956. BTW static type-checking is no excuse to stick with a early-bound language like Java either. If you take a look at Strongtalk you will see that you can have your cake an eat it too. http://www.strongtalk.org/ The bottom line is that Java was never destined to be the last word in computer science. It was a tactical language, rushed to market, that fitted nicely between C++ and Smalltalk and allowed Sun, Oracle etc to fend off the impending threat from Microsoft on the Server in the mid-90's. I think it is time to move the debate beyond brands like Java and Ruby and to focus on programming concepts like late-binding, polymorphic message sends and class reshaping. Trying to make Java more dynamic is a real nightmare, and you would not start with the current JVM. Put it this way the lead of JSR292 to make the JVM more dynamic is an old Smalltalker, who has given up on the job and left Sun. That speaks volumes to me. Don't expect Java to be fully dynamic any time soon. The web is dynamic (which is why incidently that JavaScript is also dynamic and is based on Self), and I believe that the future of the web will be dominated by mobile objects written in dynamic langauges, I'm sure of it. Ruby, Groovy, Python etc is just the start, and they are here to stay, so get use to it :^).
  12. Re: Of course[ Go to top ]

    I think you sell Java short when you say things like... "BTW static type-checking is no excuse to stick with a early-bound language like Java either. If you take a look at Strongtalk you will see that you can have your cake an eat it too." Yeah, I can get late binding and strong type checking but will the same code run on almost every machine known to mankind? Nope. Does that language offer vast libraries used by the largest enterprises? Nope. Java has its strengths and people are to quick to forget them when they are point out its flaws. On the other hand, I agree that we should always look at new languages to see what they offer. Finally, the old Smalltalker who left Sun who was working to make Java more dynamic holds no meaning whatsoever unless he's publicly stated his reasons. People leave companies all the time for many many different reasons. You're making a big assumption about his motives.
  13. Re: Of course[ Go to top ]

    I think you sell Java short when you say things like...

    "BTW static type-checking is no excuse to stick with a early-bound language like Java either. If you take a look at Strongtalk you will see that you can have your cake an eat it too."

    Yeah, I can get late binding and strong type checking but will the same code run on almost every machine known to mankind? Nope. Does that language offer vast libraries used by the largest enterprises? Nope. Java has its strengths and people are to quick to forget them when they are point out its flaws. On the other hand, I agree that we should always look at new languages to see what they offer.

    Finally, the old Smalltalker who left Sun who was working to make Java more dynamic holds no meaning whatsoever unless he's publicly stated his reasons. People leave companies all the time for many many different reasons. You're making a big assumption about his motives.
    I'm not trying to sell Java short. I'm just pointing out it's limits. The issue like I said should be the right tool for the job. Today the job is web applications. In the rich internet application space Java is being out done by C# with WPF and ActionScript with Adobe Flex/Apollo. If you aren't looking to web 2.0+ type apps then a static language like Java may well be fine. C++ still flourishes in many domains. I feel that for web applications that the future is dynamic. BTW the JSR292 lead was Gilad Bracha, and he has given a detailed presentation at the 2006 Lang.NET dynamic language symposium, that clearly describes the limits of the JVM for dynamic languages. The line "Don't expect the JVM to be dynamic anytime soon" is almost a direct quote: http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/GiladBracha-final.wmv When I first championed the use of Java back in 1996, it was conceptually a better language for server-side application development then C++, even though C++ had many of the benefits Java has today over languages like Ruby. Do you remember Java 1.0 and AWT? It was pretty rough around the edges, poor library support and it was slow, but productivity won through and library support and ubiquity followed. So like I said, we should really be discussing the language features that are needed for the web applications of the future.
  14. Re: Of course[ Go to top ]

    "So like I said, we should really be discussing the language features that are needed for the web applications of the future. " I agree but Java and Ruby are about the same age and don't forget that Smalltalk had almost all of Ruby's features 20 years before Ruby existed. There's a reason why a language comes out ahead beyond the mere sex appeal of the language semantics. The language has to prove itself in the enterprise development world to really take off and most languages fail to do that for a wide variety of reasons. Java, for all its faults, was able to make the cut. There's also nothing inherent in Java that makes it any less capable of doing rich internet apps than it is doing any other kinds of apps.
  15. Re: Of course[ Go to top ]

    "So like I said, we should really be discussing the language features that are needed for the web applications of the future. "

    I agree but Java and Ruby are about the same age and don't forget that Smalltalk had almost all of Ruby's features 20 years before Ruby existed. There's a reason why a language comes out ahead beyond the mere sex appeal of the language semantics. The language has to prove itself in the enterprise development world to really take off and most languages fail to do that for a wide variety of reasons. Java, for all its faults, was able to make the cut. There's also nothing inherent in Java that makes it any less capable of doing rich internet apps than it is doing any other kinds of apps.
    Hi Marc, You make a lot of statements. You can make a number of arguments for the success of Java over say Smalltalk, not all technical. Equally if we were in 1998ish I could make similar arguments for the success of Visual Basic over say Smalltalk. Visual Basic was by far the most popular language then. Today many of those same arguments would appear foolish. For me popularity is not an indicator of being the right tool for the job. C/C++ is a system language yet it is still used as a high level application language by many who still insist to hand-code garbage collection in their applications themselves, etc. Like I've said, we should really be discussing language features and the appropriateness for the web. Early-binding at compile time to an interface that exists on the other side of the web (like we are encouraged to do with WSDL for instance) is not a good idea, because every time that remote interface changes (like someone choosing to add an additional method), all the remote clients will break, and new stubs are need and the clients must be re-compiled, and re-deployed. This is very brittle and IMO the main reason why CORBA failed (so we are doing it all over again :^)). As for the web and REST, it doesn't work that way. Web pages are self describing, and the HTTP interface is uniform across all servers. So when you add a link to your web page, all existing clients (and thats all the browsers in the world) can update themselves dynamically (well once your user presses refresh). A dynamic message send has similar dynamic semantics, this is very different from a virtual function call which is resolved (mostly) at compile time. This is just one example of inapropriateness. BTW C# and ActionScript (as I understand it) don't fare any better in this regard either. Take a look at this site, were a guy is rectifying this problem (amongst others) by layering Lisp then Smalltalk as a Lisp DSL on top of Flex/WPF: http://vistasmalltalk.wordpress.com/ He is doing this stuff for a reason, and for me it points to the future. Another site worth checking out is Croquet: http://www.opencroquet.org/index.php/Main_Page The stuff they're doing is miles ahead of anything you could do with Java.
  16. Re: Of course[ Go to top ]

    Today the job is web applications. Is it? I have come clients and some pending clients who hate web apps, at least those that they use pretty much all day. In the rich internet application space Java is being out done by C# with WPF and ActionScript with Adobe Flex/Apollo. It is? How? With Java, I can have a client that functions in the browser, via Web Start or deployed otherwise and have them function the same. WPF is not barely out and one major .Net magazine suggest you not use it right now. Also, WPF in the browser doesn't function like WPF on the desktop. (And it only works in Windows ) And Flex/Apollo, well they have their good points but are not as flexible as Java/Swing/Groovy. So, are these tools doing good things? Sure. But out doing Java? Not.
  17. Re: Of course[ Go to top ]


    Today the job is web applications.

    Is it? I have come clients and some pending clients who hate web apps, at least those that they use pretty much all day.


    In the rich internet application space Java is being out done by C# with WPF and ActionScript with Adobe Flex/Apollo.

    It is? How? With Java, I can have a client that functions in the browser, via Web Start or deployed otherwise and have them function the same. WPF is not barely out and one major .Net magazine suggest you not use it right now. Also, WPF in the browser doesn't function like WPF on the desktop. (And it only works in Windows ) And Flex/Apollo, well they have their good points but are not as flexible as Java/Swing/Groovy.

    So, are these tools doing good things? Sure. But out doing Java? Not.
    If you define "web apps" as HTML, Javascript and AJAX then I can understand why your user's don't like them. I don't like them either. When I first started using Java, Applets where meant to be the preferred internet application solution, and html and Javascript was just a quick and dirty interim fix until Netscape won through and Applets became ubiquitous. Well the problems with Applets have finally been solved, but now Applets are called Flex/WPF RIA Apps and the VMs used are Flash and .Net. This is what I mean by Java being out done! The web isn't standing still, and people are already integrating Ruby with Flex today. I see more changes coming, and I just don't think Java is that well positioned.
  18. Re: Of course[ Go to top ]

    ...I do not know the specifics of resin, but I'd guess that it can only deal with 'hot-swap' changes that do not change the 'shape' of classes without having to do a full redeploy...
    I don't know how Resin works internally and know less about JSR292. But I'm sure that Resin treats ".java" and configuration files exactly like ".jsp". It detects a file change, recompiles it and unload/reload (part of) the application. It does it fast enought to clasify as ZTT to me. So, ZTT can be implemented with an java application server.
  19. Re: Of course[ Go to top ]

    I think it is time to move the debate beyond brands like Java and Ruby and to focus on programming concepts like late-binding, polymorphic message sends and class reshaping. Trying to make Java more dynamic is a real nightmare, and you would not start with the current JVM. Put it this way the lead of JSR292 to make the JVM more dynamic is an old Smalltalker, who has given up on the job and left Sun. That speaks volumes to me. Don't expect Java to be fully dynamic any time soon. The web is dynamic (which is why incidently that JavaScript is also dynamic and is based on Self), and I believe that the future of the web will be dominated by mobile objects written in dynamic langauges, I'm sure of it. Ruby, Groovy, Python etc is just the start, and they are here to stay, so get use to it :^).
    Paul, I've been on your side on these types of debates in the past (cue a Steve Zara post), but you're way off on this stuff about "dynamic languages". I advise you to lurk over at Lambda-the-ultimate a bit to get some insight on these "dynamic" debates. The bottom line is that dogmatic late-binding advocacy isn't very interesting or even very realistic. Boo and Nemerle both have late-binding options in otherwise static, type-inferred languages. Most of the critcism I see regarding Java is mostly boiler-plate related. You can have your cake and eat it too regarding static and dynamic typing.
  20. Re: Of course[ Go to top ]

    I think it is time to move the debate beyond brands like Java and Ruby and to focus on programming concepts like late-binding, polymorphic message sends and class reshaping. Trying to make Java more dynamic is a real nightmare, and you would not start with the current JVM. Put it this way the lead of JSR292 to make the JVM more dynamic is an old Smalltalker, who has given up on the job and left Sun. That speaks volumes to me. Don't expect Java to be fully dynamic any time soon.

    The web is dynamic (which is why incidently that JavaScript is also dynamic and is based on Self), and I believe that the future of the web will be dominated by mobile objects written in dynamic langauges, I'm sure of it. Ruby, Groovy, Python etc is just the start, and they are here to stay, so get use to it :^).



    Paul, I've been on your side on these types of debates in the past (cue a Steve Zara post), but you're way off on this stuff about "dynamic languages". I advise you to lurk over at Lambda-the-ultimate a bit to get some insight on these "dynamic" debates. The bottom line is that dogmatic late-binding advocacy isn't very interesting or even very realistic. Boo and Nemerle both have late-binding options in otherwise static, type-inferred languages. Most of the critcism I see regarding Java is mostly boiler-plate related. You can have your cake and eat it too regarding static and dynamic typing.
    Hi Frank, Nice to hear from you. I think we are in agreement (again) :^). My view that late-bound, dynamic languages are better suited to the web has nothing to do with static type checking, and I agree that the two issues are orthogonal. See my earlier post where I mention Strongtalk: http://www.theserverside.com/news/thread.tss?thread_id=45000#231039 The languages you describe as I understand it are late-bound and dynamic. My view is that the web is dynamic, and we should aim to get to the stage where we can mashup software objects written by different people at different times, across the web in the same way that we mashup web pages using HTML and Javascript today. You can do what ever checks you like at compile-time, but that should not fix the binding for ever more at runtime. At runtime you should be-able to swap and change, plug and play, and interface with any object that meets the required interface contract without having to re-compile. This is my point.
  21. Re: Of course[ Go to top ]

    You can do what ever checks you like at compile-time, but that should not fix the binding for ever more at runtime. At runtime you should be-able to swap and change, plug and play, and interface with any object that meets the required interface contract without having to re-compile. This is my point.
    Just to be clear, by "interface contract", I do not mean a static interface, like a Java Interface or WSDL. No, what I mean is any service object that provides the behaviour you require as a client. If for example you find a service object on the web that satisfies the behaviour you want, and you stumble across another object that you want to 'munge' with that service to provide a new service, then you many need to write some 'glue code' to adapt the messages between them to what is required. The key here is that the services are encapsulated behind message sends, and all they expose is their message interface. You are then free to script and mashup to these message interfaces without worrying about Class (implementation) or Type (fixed Interfaces).
  22. Re: Of course[ Go to top ]

    I think this statement is incorrect. I believe 'hot-swapping' is an outstanding Java feature planned forn a future JSR (JSR292). I do not know the specifics of resin, but I'd guess that it can only deal with 'hot-swap' changes that do not change the 'shape' of classes without having to do a full redeploy.
    I'll take the risk and push out OSGi as the answer here. What do other people think? My early impression is that retraining enterprise developers in the modular approach enabled by OSGi would address many of the most prevalent and hard-to-fix problems we see in medium- and large-scale enterprise software deployments (read: the Java EE space) today. Lest it pass unnoticed, I couldn't help but be amused by Gavin King's latest backhanded swipe at Spring ("It's yesterdays technology everybody! Really!") I've always wondered why the alpha geeks at JBoss developed such a deep-seated grudge against Spring. In recent months they've largely abandoned the rather unseemly FUD campaign of yore, but it seems the old green-eyed monster still lurks in their hearts. Funny, and sad. - Christopher
  23. Re: 10 seconds[ Go to top ]

    I use Eclipse plus the Tomcat plugin from Sysdeo when I want to see my changes immediately on the web page. Anyway, the 10 seconds [sic] it takes to compile gives me time to check out the latest on TSS.
  24. Nietzsche pattern[ Go to top ]

    What doesn't kill Java makes it stronger. IMHO Ruby or more specifically Rails is a sideshow that will see its conventions and language become assimilated into bytecode. It's the VM not the language. Now that Vista is out, Microsoft will turn its agile teams to tools. The MS FUD factory hasn't even begun to spew.
  25. I recommend Ruby and PHP folks keep using those technologies. I'll use SEAM. It has a big enough community at this point, it doesn't matter what people say or do. I would LOVE for Oracle and Weblogic to speed up efforts to make SEAM compatible with their app servers.
  26. SEAM[ Go to top ]

    SEAM is not compatible with OC4J?
  27. Re: SEAM[ Go to top ]

    I have only used it on JBoss. Last I checked it had some issues, but for all I know SEAM may work fine with oc4j now.
  28. My view is that, while the Ruby fanboys are doubtless unnecessarily loud and often blind to the shortcomings of their own toy, they are pointing out valid deficiencies in the Java development model. Filter through the noise and see if there's a useful core message! Layers. Well, hmm, to build a DB-aware Web app you have to jam together a bunch of frameworks/libraries/whatever. At the very least, you'll be dealing with, say Hibernate and Stripes or maybe Wicket or Tapestry. OK, they can be made to work together, but you have to do the impedance matching yourself. Chances are you'll have to build 2 or more sets of XML files for configuration. And maybe deployment descriptors on top. Compile time. One app I'm involved with has 10,000 source files (!) and requires about 15 minutes to compile. Incremental compilation would be cool but I don't have enough control (= I'm not allowed) to change build process, i.e. to change the Ant task in all the ways this would require. One of the impediments to incremental compilation is ejbgen. If the parts of my project could dynamically link via reflection or something, that might do away with the meta-compilation process and make incremental compilation much easier. Deployment time. The app I mentioned takes 4 minutes to deploy. Again, this is partly due to boneheaded policies in place; it should be possible to replace individual JAR files rather than the complete EAR. But it would be still sweeter if a single source file could be replaced in a running program. What has improved? Thanks to merciless griping,
    • Hot swapping at the class level is possible, at lease in the debugger, since about 1.4.
    • In many cases, XML configuration files can be replaced by annotations.
    • Application servers allow class swapping in development mode.
    This is all good news even if it comes a bit late for the project I'm on; but there's room to improve even more. It ain't gonna happen if people pretend to be perfectly happy.
  29. One app I'm involved with has 10,000 source files (!) and requires about 15 minutes to compile. Incremental compilation would be cool but I don't have enough control (= I'm not allowed) to change build process, i.e. to change the Ant task in all the ways this would require. One of the impediments to incremental compilation is ejbgen. If the parts of my project could dynamically link via reflection or something, that might do away with the meta-compilation process and make incremental compilation much easier.
    As soon as I read 10K source files I guessed that many of these had to be generated. Still, it seems like way to much to put into one compilation unit. Couldn't you break this system up into separate libraries? That seems like it would be more effective than custom ant tasks. I'm not sure I get the connection between a weakness in Java and your case example. But your point about pain points=innovation rings true.
  30. given the policy is a major factor in how you build and develop, using Ruby would also slow down. The problem is stupid company policies that slow developers down. I've seen it first hand and honestly, to me the technology doesn't matter at that point. It's about the business exercising control over the developers because they distrust IT. sure, using Ruby might start out faster, but once the control goons get wind of it, they'll put up all sorts of barriers and you're back to the same situation. the solution is to fix the company policies and practices. my bias 2 cents. peter
  31. This is true, of course. Have Yo ever read Popleware by Tom DeMacro? "Languages are important, because they affect the way you thing about the problem, but again, they can have only impact on the implementation part of the project. Because of their exaggerated claims, some of our newer languages qualify as laetrile. Sure it may be better to do new application in PowerBuilder, for example, rather than COBOL, but even before PowerBuilder there were better ways than COBOL: niche tools that make inquiry and update pretty easy. Unless you've been asleep at the switch for the past few decades, change of a language won't do much for you. It might give you a five percent gain (nothing to sneeze at), but not more."
  32. Dang it, you made me whip out the dictionary - and on a Friday no less! laetrile:a drug derived especially from apricot pits that contains amygdalin and has been used in the treatment of cancer although of unproved effectiveness. So does the more slang usage mean "of unproved effectiveness" or does it mean something else when you use it more loosely? I'm not sure what you are measuring when you say 5% gain. Developer productivity, maintenance, lines of code (or reduction in lines of code), etc?
  33. Dang it, you made me whip out the dictionary - and on a Friday no less!

    laetrile:a drug derived especially from apricot pits that contains amygdalin and has been used in the treatment of cancer although of unproved effectiveness.

    So does the more slang usage mean "of unproved effectiveness" or does it mean something else when you use it more loosely?

    I'm not sure what you are measuring when you say 5% gain. Developer productivity, maintenance, lines of code (or reduction in lines of code), etc?
    It's not me. It's qutoe from Tom DeMarco well knownAll time classic book. Generally i do agree with statement above.
  34. Agreed.[ Go to top ]

    The problem here is that most of these folks are comparing either the previous generation of Java technologies (Struts+Spring+Hibernate+J2EE) or the even older generation (EJB2+J2EE) with a totally new technology stack that is still maturing (RoR) and will take another 2+ years to really be ready for serious deployments. This is quite unfair, of course. J2EE is now >5 years old! This is obsolete technology! Arguing against EJB2 is fighting a strawman. Likewise, the adhoc Struts+Spring+Hibernate solution is almost 5 years old, and showed its warts over the years. That's why we have the new crop of frameworks to address those problems and reach a new level of simplification. A fair comparison would be to compare Ruby technologies to the new generation of Java technologies (Seam/Grails/whatever+EE5). If you do this comparison fairly, you'll see that the EE5 stacks are more mature and stable for production usage, but somewhat less documented and well-understood for development. The underlying machinery is there, but we don't have the books and the real-world success stories just yet, and some of the APIs are still changing. The following points stick out: * architectural complexity - the new Java EE 5 based stacks are just as simple in terms of layering as the Rubyish solutions * advanced functionality - Java wins by a wide, wide margin (eg. ActiveRecord vs. Hibernate3, LOL!) * code level elegance - there are wins on both sides: Ruby has some nice elegant language features, but also some awful warts in the way Rails uses these features (compare RHTML to Facelets). Groovy brings many of these same nice things to the Java platform. * LOC - there is now no longer much difference in linecount between the Rubyish and Java-based frameworks (of course, the typesafe nature of Java means a few more characters on type declarations, but this is a feature, not a bug) - in many usecases, a Seam solution will have a smaller linecount than a Rails solution * Code/compile/test cycle - the idea that Java developers are sitting around waiting for their compiler to run is hilarious - this is simply not a problem and never has been. OTOH, incremental hot deployment certainly has been a major problem for the previous generations of Java technologies, but this problem is being addressed and solved in the new generation (Seam, Tapestry and Grails now all feature some level of support for this). Meanwhile, the fact that the Java compiler spots all kinds of common errors without even needing to execute the code (wow!) speeds up development considerably for most people. * Refactoring and Tooling - Java kills Ruby dead and this is a problem that cannot be fixed in Ruby or any other language without static typing. I will surrender my "rename method" refactoring when you pry it out of my cold dead fingers! * Deployability - don't make me laugh - Java is almost a decade ahead. JBoss or WebLogic vs. Mongrel??!!! * Ecosystem - the Java ecosystem is immense, viciously competitive, and amazingly self-correcting. Ruby has yet to reproduce anything remotely similar. But by all means, let the bashing continue, life would just be no fun without it ;-)
  35. Re: Agreed.[ Go to top ]

    Likewise, the adhoc Struts+Spring+Hibernate solution is almost 5 years old, and showed its warts over the years.
    A fair comparison would be to compare Ruby technologies to the new generation of Java technologies (Seam/Grails/whatever+EE5).
    LoL! So 'Struts+Spring+Hibernate' was 2006, 'Seam/Grails/whatever+EE5' is 2007? Please tell me the 'stack' for 2008 so that I can skip the drivel for the rest of the year!
  36. Re: Agreed.[ Go to top ]

    "LoL! So 'Struts+Spring+Hibernate' was 2006, 'Seam/Grails/whatever+EE5' is 2007? Please tell me the 'stack' for 2008 so that I can skip the drivel for the rest of the year!" Casual, You ever see what a struts-config.xml file or a Spring applicationResource.xml file looks like on your average enterprise app? ugly Yea I know...Struts2 and Spring2 have fixed that, but Struts1 and Spring1 were XML ugly.
  37. Re: Agreed.[ Go to top ]

    "LoL! So 'Struts+Spring+Hibernate' was 2006, 'Seam/Grails/whatever+EE5' is 2007? Please tell me the 'stack' for 2008 so that I can skip the drivel for the rest of the year!"


    Casual,
    You ever see what a struts-config.xml file or a Spring applicationResource.xml file looks like on your average enterprise app?
    ugly

    Yea I know...Struts2 and Spring2 have fixed that, but Struts1 and Spring1 were XML ugly.
    I seriously doubt Struts2 and Spring2 fixed the ugly configuration issue. Did the upgrades come and talk to my developers and force them to crack open the documentation for these technologies, or give them a lecture on what classes should be Sprung verses those that work with good old Java "new"? While not ideal you could make pre-2.0 Spring manageable and even tame Struts. The problem is that configuration is still just code, but by putting it in XML developers treat it like a 2nd class citizen and don't review/refactor it. Ah corporate development...
  38. Re: Agreed.[ Go to top ]

    You ever see what a struts-config.xml file or a Spring applicationResource.xml file looks like on your average enterprise app? ugly Yea I know...Struts2 and Spring2 have fixed that, but Struts1 and Spring1 were XML ugly.
    IMO, the technology must be very immature when the hypes change so frequently. No matter what is praised today we know that it will be outdated next year. That's not a basis for serious professional work.
  39. Re: Agreed.[ Go to top ]

    Of course, Gavin agrees .... kind of, well as long as it's his currently favored stack... he's not advocating java, but what he's see's as "right" stack.... currently. How simplistic.... BTW it should be about time that this "Pragramtic Ruby Programmers" adopt another language... hey would'nt that be fun: Then we can start bashing Ruby.
  40. Re: Agreed.[ Go to top ]

    Of course, Gavin agrees .... kind of, well as long as it's his currently favored stack... he's not advocating java, but what he's see's as "right" stack.... currently.

    How simplistic....

    BTW it should be about time that this "Pragramtic Ruby Programmers" adopt another language... hey would'nt that be fun: Then we can start bashing Ruby.
    At least he has not used the buzzword "EJB"
  41. Re: Agreed.[ Go to top ]

    Of course, Gavin agrees .... kind of, well as long as it's his currently favored stack... he's not advocating java, but what he's see's as "right" stack.... currently.

    How simplistic....

    BTW it should be about time that this "Pragramtic Ruby Programmers" adopt another language... hey would'nt that be fun: Then we can start bashing Ruby.


    At least he has not used the buzzword "EJB"
    3
  42. He is right about everything but the deployment cycle. Yeah sure with jetty or tomcat it is less of a problem but I dont live in a jetty/tomcat world unfortunately. I live in websphere world and there seems no escape from it. When I do small projects on behalf of my own company everything is fine and I enjoy my proffesion but when I work on larger projects it is always websphere. I can work for 3 months with it max, otherwise I start barking at my manager, suffer from sleepless nights, lose weight and hair, look like shit and need prozac or derivatives to get myself going. I had an offer the other day with the best hourly rate ever but I refused it because of this. I know when my money runs out and I cannot find a small project I have no choice but to work with it again, thinking about it alone pumps the cold sweat out of my armpits already. I stink, yak. ps. just kidding about the prozac
  43. I agree that the Java bashing has been pretty heavy of late, but it stopping altogether is just as extreme as some of the arguments have been. If we all stopped arguing about it as a community, we'd all take orders from one all-knowing entity that decides everything for us because they think they know best (and want to keep selling Windows). A little over a year ago, I read Beyond Java and, despite the kayaking stories, loved it. The Fortune 10 I work for isn't close to dropping Java development over the issues that book raises, but at least it raises them. Java's not perfect and could be better. To me, that's the point. BTW, add me to the list of people who likes the idea of running Rails on the JVM. I still wish JRuby could get a little more mature so my sys/admins and upper management could keep the app servers they've come to depend on but our development staff could choose to Ruby when situations warranted it. Now? No way you get Ruby past an architecture review because of the relatively untested (compared to 10+ years of Java) runtime environment.
  44. An example that demonstrates the maturity and wide selection of libraries in Java compared to Ruby: Last week the Mole Rails plugin received quite a bit of attention: http://liquidrail.com/2007/4/8/mole-plugin-inspect-the-rails/ "The MOle allows you to precisely analyze how your customers are interacting with your rails application." What's interesting is Java has had a similar library for over 2 years: http://www.opensymphony.com/clickstream/ ----------- A lot of Ruby development is solving problems that were fixed years ago.
  45. really ridiculous, why people try to compare java with RoR. obviously RoR is good on some scenario. We don't write our java application to meet one time client requirements. we plan a java application to make it future expandable. thats why we introduce many separation and layers. Active record is good but why we will choose it? when we are using some thing better. i think DAO and Model separation is much more manageable and good for serialization. in case of serialization how Active record works? many stuffs we shouldn't mash up with Java.. rather go for Google mash up ;) best wishes,
  46. Ok, sure I'll stop now...[ Go to top ]

    You are right, this ridiculous Java bashing needs to stop, I'll go back to using all the Java frameworks, and I'll just forget that I could get done in ActiveRecord what only takes me 4 or 5 classes in Java. Then, I'l hire the extra person it is going to take to complete this project becuase it is much easier to keep the web sites on Rails. When I recommend the extra hires, I'll copy them on this article as justification. I'll stop trying to get Spring + Hibernate to get close to the ease of ActiveRecord, and we'll just go back to handcrafting all of our DAOs even though we've already deivered a functional prototype to the customer. I tell them I've had a change of heart.
  47. Re: Ok, sure I'll stop now...[ Go to top ]

    You are right, this ridiculous Java bashing needs to stop, I'll go back to using all the Java frameworks, and I'll just forget that I could get done in ActiveRecord what only takes me 4 or 5 classes in Java. Then, I'l hire the extra person it is going to take to complete this project becuase it is much easier to keep the web sites on Rails. When I recommend the extra hires, I'll copy them on this article as justification.

    I'll stop trying to get Spring + Hibernate to get close to the ease of ActiveRecord, and we'll just go back to handcrafting all of our DAOs even though we've already deivered a functional prototype to the customer. I tell them I've had a change of heart.
    All well and good, but if you've seen the light how come you are still haunting the J2EE boards?
  48. Re: Ok, sure I'll stop now...[ Go to top ]

    You are right, this ridiculous Java bashing needs to stop, I'll go back to using all the Java frameworks, and I'll just forget that I could get done in ActiveRecord what only takes me 4 or 5 classes in Java. Then, I'l hire the extra person it is going to take to complete this project becuase it is much easier to keep the web sites on Rails. When I recommend the extra hires, I'll copy them on this article as justification. I'll stop trying to get Spring + Hibernate to get close to the ease of ActiveRecord, and we'll just go back to handcrafting all of our DAOs even though we've already deivered a functional prototype to the customer. I tell them I've had a change of heart.
    Here is a dumb question. What happens if you work at a company where developers are not allowed to run SQL and absolutely have to go through modeling with a Modeler and then wait for the modeler to talk to the DBA. The DBA then creates the tables. Once that is done, the developers have to write stored procs? Can ActiveRecord use stored procs? If you have to wait 2-4 months to get a physical database, how does ROR or active record help? Does ROR shorten your development time in this kind of environment? Better yet, what happens when your data comes from several databases include a mainframe? And can you cluster ROR to provide fault tolerance and disaster recovery capabilities? I'm asking because I've never used ROR or active record. peter
  49. Re: Ok, sure I'll stop now...[ Go to top ]

    >Here is a dumb question. What happens if you work at a company where developers are not allowed to run SQL and absolutely have to go through modeling with a Modeler and then wait for the modeler to talk to the DBA. The DBA then creates the tables. Once that is done, the developers have to write stored procs?
    In this scenario I don't think the question is RoR vs Java. I think it's time to ask yourself if it's time for another job?
  50. Re: Ok, sure I'll stop now...[ Go to top ]

    >Here is a dumb question. What happens if you work at a company where developers are not allowed to run SQL and absolutely have to go through modeling with a Modeler and then wait for the modeler to talk to the DBA. The DBA then creates the tables. Once that is done, the developers have to write stored procs?
    In this scenario I don't think the question is RoR vs Java. I think it's time to ask yourself if it's time for another job?
    So what you're saying is that everyone working at a large financial institution with these types of processes should find a new job? Sure that makes "a lot" of sense. There's a reason why some applications have this kind of process. Dismissing a real concern does not provide a solution. I've worked at companies with and without these kinds of processes. There are legitimate reasons why these kinds of processes are in place. Is it the best thing for developers? Sometimes it is and sometime it's not. my bias 2 bits peter
  51. Re: Ok, sure I'll stop now...[ Go to top ]

    There's a reason why some applications have this kind of process. Dismissing a real concern does not provide a solution. I've worked at companies with and without these kinds of processes. There are legitimate reasons why these kinds of processes are in place. Is it the best thing for developers? Sometimes it is and sometime it's not.

    my bias 2 bits

    peter
    Hi Peter, I saw your post, and didn't respond because I didnn't know what to say, whilst being polite. Getting another job isn't such a bad idea:^) Seriously, the problem here is culture. In the Agile community they accept that software is mostly a craft and have given up on silly rules and have chosen to value highly skilled people over fixed and deterministic processes. The things is that what is the right thing to do, depends on the circumstance and the team should be enabled and empowered to do exactly what it thinks is best. This should include language choice too (yes you should be able to use Ruby, JRuby, Python or whatever if you decide that is the best solution to your specific problem). The real question is why would you have it any other way? BTW. You raise a valuable point about culture, and I think the need for a fixed set or rules that everyone can follow is a cultural trait that leads to these types of debates in the first place. We do not need to choose Ruby over Java for everything. We can use both. What we are talkng about is choice, which is a good thing. Unfortunately most developers want to be lead, and do not understand enough about programming languages to exercise choice sensibly themselves. I've blogged on this particular subject: http://pab-data.blogspot.com/2007/03/programming-languages-follow-leader.html I would suggest that you look at Agile values and principles and try and introduce them into your organisation. If the powers that be (e.g. the "System Architect" or the strategy group) don't like giving up power to the people that actually write the code, then leave. BTW, Agile practices stemed from experiences with Smalltalk. Comming back to the idea of continuous change and software development as a craft, I don't believe this historical fact is an accident.
  52. Agile Approach[ Go to top ]

    If the powers that be (e.g. the "System Architect" or the strategy group) don't like giving up power to the people that actually write the code, then leave.
    The problem might be that the "powers that be" relied on the "good and agile people" once to often. I also like to think of software development as a craft. The problem is that a lot of developers, architects, designers and requirement engineers in the wild are actually odd-jobs. By the time this is realized, a lot of money has been wasted. And to overcome this problem to a certain extend, people tend to use processes. A process that has been proven to at least safe a mission critical database from being bogged down by a programmer writing stupid SQL is to wrap every call to the database in a stored procedure and have it checked by someone who understands what is actually happening. Also it is an excellent tool that makes a company realize that some in depth sql expert knowledge may be required apart from sql 101 :-). Another way can be to use an optimized O/R mapping framework.
  53. Re: Agile Approach[ Go to top ]

    Debates like this seem to confuse the business of delivering software products with the craft of software development. An agile development skillset/toolset/mindset are valuable assets for any individual developer. However, the best approach to utilising those skills, tools and attitudes on a team or across a business is a much more complex question. It's a shame that this part of the equation is not considered with much maturity by the average software craftsperson. I have seen agile teams bring new products to market quickly and efficiently, and I have also seen agile teams piss-money-up-the-wall at a business destroying pace. I am just stunned when I see comments from obviously intelligent professionals, who advocate quitting a job because the business has a strong process and a rigorous approach to change management (presumably because of the scary monetary/reputation cost of screw-ups in that business). References to the "powers that be (System Architect or the strategy group)" as some kind of illegitemate/hostile agent, rather than another legitimate constraint (like programming language, hardware choice or data format) highlight the gulf of misunderstanding that exists between business and their technology providers. I am not sure that optimising our programming language choice will help much solving that problem :) Cheers J
  54. Re: Agile Approach[ Go to top ]

    I have seen agile teams bring new products to market quickly and efficiently, and I have also seen agile teams piss-money-up-the-wall at a business destroying pace.
    Absolutely!
    I am just stunned when I see comments from obviously intelligent professionals, who advocate quitting a job because the business has a strong process and a rigorous approach to change management
    Well, for me the best incentive to quit a job is the ability to work in one that suits me better. Since a lot of developers don't like to work in a constrained environment this sound sensible...provided they can secure a better job, of course.
  55. Re: Agile Approach[ Go to top ]

    If the powers that be (e.g. the "System Architect" or the strategy group) don't like giving up power to the people that actually write the code, then leave.


    The problem might be that the "powers that be" relied on the "good and agile people" once to often.
    If their people weren’t any good, then obviously by definition they didn’t have "good Agile people". The bottom line is people, and building skilled teams. Maybe the powers to be should hire people they can trust, or better still learn how to develop such people internally? I fail to see how an individual (The Strategist) can make a better decision at 10,00 feet with no appreciation of the actual circumstance on the ground, then a team of intelligent individuals (notice, I say team) doing the job day to day. Just because the process says so doesn't mean you are making a good decision. People create processes, so having a process doesn't avoid human error and bad decisions, it just means that you sanction bad decisions because they are written down and allow you to say, "it wasn't my idea the process told me to do it". You need teams that are enabled (have the skill) and empowered (have the authority) to do the right thing
    also like to think of software development as a craft. The problem is that a lot of developers, architects, designers and requirement engineers in the wild are actually odd-jobs. By the time this is realized, a lot of money has been wasted.
    I agree about the odd-jobs. There is a whole industry out there that makes its money out of complicating and obfuscating what is essentially a single craft. Fashion Design, Journalism or a number of other creative professions would not countenance such an army of "hangers on". If you don’t code, then you’re not producing Software. It is that simple IMO. How for example are you to know whether the mix of projects you are currently being presented with matches your current tool set (programming language, frameworks, middleware etc), if you aren’t using those tools on a daily basis? How are you to decide if you are not intimately involved? You can’t so you stick with inappropriate tools based on a decision made by some Architect (or perhaps you just follow the corporate standard defined years ago by strategy).
    And to overcome this problem to a certain extend, people tend to use processes.

    A process that has been proven to at least safe a mission critical database from being bogged down by a programmer writing stupid SQL is to wrap every call to the database in a stored procedure and have it checked by someone who understands what is actually happening. Also it is an excellent tool that makes a company realize that some in depth sql expert knowledge may be required apart from sql 101 :-). Another way can be to use an optimized O/R mapping framework.
    I would like to think that suitable supervision and oversight existed so that a junior person wasn't left hung out to dry (pair programming anyone?). BTW, why is someone who “doesn’t know what he is doing” being asked to make database changes? My point is that these are all people issues. The success of a development organisation comes down to its people and teams. Pretending otherwise and acting as though there is some deterministic, scientific, pre-canned that solution to Software Development that is applicable in all scenarios (the mythical “Silver Bullet”), is largely why the Software Industry find itself in the perpetual mess it is in today (remember that over 60% of projects fail!). PS. Sorry for the rant, but I’ve heard this same lame excuse so many times! It's tiresome.
  56. Re: Agile Approach[ Go to top ]

    I agree about the odd-jobs. There is a whole industry out there that makes its money out of complicating and obfuscating what is essentially a single craft. Fashion Design, Journalism or a number of other creative professions would not countenance such an army of "hangers on". If you don’t code, then you’re not producing Software. It is that simple IMO.
    I don't have any experience of those industries and so perhaps I am being ignorant, but don't journo's work with sub editors, editors and publisher to get their stories on the page? Don't fashion designers work with buyers and manufacturers to get the clothes on racks? I would assume that all of these extra people feel like they are part of the creative production line, in the sense that they influence some of the important qualities of the final product. To my mind that is the role of the architect or strategist - to look across projects, products and businesses to determine some of the key qualities of the finished software product. This is an especially helpful role when you are dealing with a portfolio of products or systems. In a similar vein, policies and procedures should be used to capture important learnings that are properly outside the scope of a single project or product. Of course, in practice, a bad architect (or process or strategy) is a pain and can cause trouble, especially when legitimate authority is used as a substitute for technical authority. However, I don't see that they are intrinsically any more trouble than bad programmers ... So we are back to the notion that great teams are the solution. I would not dare argue with this notion, especially when it so fervently stated ;) In fact at the start of every new project I always have a task called: "assign great team". Er, I think that I might be a bit offtopic now. Cheers J
  57. Re: Agile Approach[ Go to top ]

    I don't have any experience of those industries and so perhaps I am being ignorant, but don't journo's work with sub editors, editors and publisher to get their stories on the page? Don't fashion designers work with buyers and manufacturers to get the clothes on racks? I would assume that all of these extra people feel like they are part of the creative production line, in the sense that they influence some of the important qualities of the final product.
    The people you mention don't deal with the product conception but the product distribution, selling, ... It's like saying that the person who puts the software in the box is part of the producing team.
  58. Re: Agile Approach[ Go to top ]

    I don't have any experience of those industries and so perhaps I am being ignorant, but don't journo's work with sub editors, editors and publisher to get their stories on the page? Don't fashion designers work with buyers and manufacturers to get the clothes on racks? I would assume that all of these extra people feel like they are part of the creative production line, in the sense that they influence some of the important qualities of the final product.


    The people you mention don't deal with the product conception but the product distribution, selling, ... It's like saying that the person who puts the software in the box is part of the producing team.
    Editors and publishers set constraints on the content that appears in their products. Whilst they don't write the words of the individual stories they have a big impact on the shape of the publication that the punter buys. It's quite a different role from the printing press operator, who is unlikely to "influence ... important qualities of the product". To stray into stating-the-obvious territory, most technical or creative projects involve several strata of collaborating professionals, between whom there is inevitably a creative tension. In the long run, mutual respect and excellent communication helps make things tick along nicely. Denying the worth of a particular strata because you reckon you can do their job better than them doesn't normally help so much. Cheers J
  59. Re: Agile Approach[ Go to top ]

    To stray into stating-the-obvious territory, most technical or creative projects involve several strata of collaborating professionals, between whom there is inevitably a creative tension. In the long run, mutual respect and excellent communication helps make things tick along nicely. Denying the worth of a particular strata because you reckon you can do their job better than them doesn't normally help so much.
    Well said.
  60. Re: Agile Approach[ Go to top ]

    To stray into stating-the-obvious territory, most technical or creative projects involve several strata of collaborating professionals, between whom there is inevitably a creative tension. In the long run, mutual respect and excellent communication helps make things tick along nicely. Denying the worth of a particular strata because you reckon you can do their job better than them doesn't normally help so much.


    Well said.
    Hi Guys, I'm all for creative tension, my issue is with inappropriate stratas. BTW I've done thos jobs, I've worked as a System Architect and a Strategist in the past. I'm all for Architects that code and I'm all for Strategist that code too. My point is about empowering teams to make decisions themselves. If the Architect and Strategist is on the team and is willing to get their hands dirty then fine. If you look at Peter Lin's original post, it refers to technical decisions that were made by people far removed from the team, and who are not on the hook to deliver a working product (Working Software). Paul.
  61. If you look at Peter Lin's original post, it refers to technical decisions that were made by people far removed from the team, and who are not on the hook to deliver a working product (Working Software).

    Paul.
    This line of debate is not so far off topic as it seems. These sratas you speak of are largely responsible for inappropriate technology choices IMO. As a freelancer, I'm often recruited to work on projects where they aren't sure of the requirements, they're not even sure of the stakeholders, but the one thing they do know for sure is that it will be written in Java 1.5 and use Weblogic 9. Why? Because this is the corporate 'Software' strategy. Now my simple question is how do you know you've got the right tool for the job, when you haven't taken a good look at the job in the first place and you haven't taken a good look at other tools? If the only tool you have in your toolbox is an hammer, then all your jobs will look like a nail! Paul.
  62. Hi Guys, In fact the more I think about this phenomena, it isn't even got anything to do with Agile versus say Waterfall. When I was trained in Software Development, technology selection occurred after requirements analysis and after high level (requirements facing) design. It was only then (technology facing design) that you made a language choice (Assembler, 3GL, 4GL etc), and not before. I would be interested in hearing from anyone who was taught otherwise. So this idea that we must use a given language for everything, and that the Strategist can make decisions without even looking at the requirements is an idea that doesn't come from Software Engineering theory. If I was to guess where it does come from I would say that it was probably conjured up in the minds of Sales people from Oracle, BEA and the like :^). Peace. Paul.
  63. Re: Agile Approach[ Go to top ]

    I'm all for Architects that code and I'm all for Strategist that code too. My point is about empowering teams to make decisions themselves. If the Architect and Strategist is on the team and is willing to get their hands dirty then fine.
    The problem is defining "team." We've got one big Oracle instance that runs countless little web applications, each in there own schema. Probably 99% of them would be better off with something lighter taken as individuals, and most probably could not justify the licensing costs. Sharing an instance certainly adds beuracracy to the equation, and additional rules. But at an enterprise level it creates efficiencies. The big Oracle DB can be treated as mission critical. It saves hardware, licensing, and maintenance money. Overall I think it is a good thing, but it does slow projects down and place "arbitrary" limits on them. Overall it is probably a net benefit. Now for every good decision like that, there are probably 5 bad ones, usually involving dictating the use of IBM products. So I completely understand your feelings. Also, I don't think you give the infrastructure people enough credit. Programming is not the center of the universe, despite what many programmers think.
  64. Re: Agile Approach[ Go to top ]

    I'm all for Architects that code and I'm all for Strategist that code too. My point is about empowering teams to make decisions themselves. If the Architect and Strategist is on the team and is willing to get their hands dirty then fine.


    The problem is defining "team." We've got one big Oracle instance that runs countless little web applications, each in there own schema. Probably 99% of them would be better off with something lighter taken as individuals, and most probably could not justify the licensing costs. Sharing an instance certainly adds beuracracy to the equation, and additional rules.

    But at an enterprise level it creates efficiencies. The big Oracle DB can be treated as mission critical. It saves hardware, licensing, and maintenance money. Overall I think it is a good thing, but it does slow projects down and place "arbitrary" limits on them.

    Overall it is probably a net benefit.

    Now for every good decision like that, there are probably 5 bad ones, usually involving dictating the use of IBM products. So I completely understand your feelings.

    Also, I don't think you give the infrastructure people enough credit. Programming is not the center of the universe, despite what many programmers think.
    hi Erik, I agree with what you say. It isn't black and white, and I'm mostly describing an 'attitude'. BTW, I do believe that this 'attitude' does have an impact on technology choice, like for example whether a team is free to use say Ruby over Java for a given project. I'm all for delegating decision making to the lowest level possible within an organisation (self organised teams), and having strategic decisions made bottom-up (independent teams working together to share resources). What I am against is heavy handed command and control, top-down. BTW. I think avoiding redundancy and optimising hardware/software choices across an organisation is an over-rated goal and can be counter-productive. Organisations are sub-optimal in many respects. For example a business unit is often free to go out and buy equipment, even when there is under utilised resources elsewhere in the organisation. Often they prefer this freedom because it puts them in control. This need for control is one of the reasons why the IBM PC took off over mini-computers and terminals for example. The overriding principle here is tying control to responsibility. If a business unit is made responsible and is accountable for delivering business results (money), then they should also be free to spend their budget anyway they see fit. And if a development team is on the hook to deliver software to a business unit who are looking for a ROI, then that development team should also be free to do what ever it sees fit to satisfy the customer (including using Ruby if they so choose). I'm polarising the argument, but I think you get my point. Paul.
  65. Re: Agile Approach[ Go to top ]

    To stray into stating-the-obvious territory, most technical or creative projects involve several strata of collaborating professionals, between whom there is inevitably a creative tension. In the long run, mutual respect and excellent communication helps make things tick along nicely. Denying the worth of a particular strata because you reckon you can do their job better than them doesn't normally help so much.
    Well said.

    Hi Guys, I'm all for creative tension, my issue is with inappropriate stratas. BTW I've done thos jobs, I've worked as a System Architect and a Strategist in the past. I'm all for Architects that code and I'm all for Strategist that code too. My point is about empowering teams to make decisions themselves. If the Architect and Strategist is on the team and is willing to get their hands dirty then fine. If you look at Peter Lin's original post, it refers to technical decisions that were made by people far removed from the team, and who are not on the hook to deliver a working product (Working Software). Paul.
    I agree that these kinds of politics problems are cultural. Sometimes the business is willing to change, but sometimes they won't. At the end of the day, it does come down to having a good team. By team, I mean programmers, architects, managers and executives. I don't believe a team that is just developers will ever succeed. my bias 4 bits. peter
  66. Re: Agile Approach[ Go to top ]

    +1 Hi Peter, I agree, and I was being a bit controversial which is sometimes a good thing if it gets people thinking :^). BTW, I've worked on very successful teams in the wider sense that got away with just customers (yes they are an important part of the team), developers (programmers), testers and obviously managers/executives. This is the simplest team possible I think. I guess I'm saying that there is no fixed formula, and I tend to prefer the flattest organisational structure possible where programmers/developers get to interact directly with the customer. Good luck with trying to get JRuby into your place. Paul.
  67. Re: Agile Approach[ Go to top ]

    +1 Hi Peter, I agree, and I was being a bit controversial which is sometimes a good thing if it gets people thinking :^). BTW, I've worked on very successful teams in the wider sense that got away with just customers (yes they are an important part of the team), developers (programmers), testers and obviously managers/executives. This is the simplest team possible I think. I guess I'm saying that there is no fixed formula, and I tend to prefer the flattest organisational structure possible where programmers/developers get to interact directly with the customer. Good luck with trying to get JRuby into your place. Paul.
    I have no plans to use JRuby at the moment, it was more of a exploration for me. I feel many of the things ROR offers are good and provide alternatives. Even though working in large institutions has drawbacks, it also provides an opportunity to work on very challenging problems. Some of the hardest problems I've encountered from a technical perspective were at large institutions. No job is going to be ideal and there's always going to be trade-offs :) peter
  68. Re: Agile Approach[ Go to top ]

    I agree about the odd-jobs. There is a whole industry out there that makes its money out of complicating and obfuscating what is essentially a single craft. Fashion Design, Journalism or a number of other creative professions would not countenance such an army of "hangers on". If you don’t code, then you’re not producing Software. It is that simple IMO.


    I don't have any experience of those industries and so perhaps I am being ignorant, but don't journo's work with sub editors, editors and publisher to get their stories on the page? Don't fashion designers work with buyers and manufacturers to get the clothes on racks? I would assume that all of these extra people feel like they are part of the creative production line, in the sense that they influence some of the important qualities of the final product.

    To my mind that is the role of the architect or strategist - to look across projects, products and businesses to determine some of the key qualities of the finished software product. This is an especially helpful role when you are dealing with a portfolio of products or systems. In a similar vein, policies and procedures should be used to capture important learnings that are properly outside the scope of a single project or product.

    Of course, in practice, a bad architect (or process or strategy) is a pain and can cause trouble, especially when legitimate authority is used as a substitute for technical authority. However, I don't see that they are intrinsically any more trouble than bad programmers ...

    So we are back to the notion that great teams are the solution. I would not dare argue with this notion, especially when it so fervently stated ;) In fact at the start of every new project I always have a task called: "assign great team".

    Er, I think that I might be a bit offtopic now.

    Cheers
    J
    Hi Jamie, Interesting subject, and yes we are off topic. I would suggest that you take a look at the industries I mentioned. In Fred Brooks "The Mythical Man Month", he states that studies have shown that there is a factor of ten between the most productive programmers and mediocre ones. In other "creative" industries their best people are rewarded at least 10 times as much. Also, their best people remain "hands on" throughout their careers (think of lawyers). Jean-Paul Gautier would not leave his most important work to a bunch of under studies, yet this happens in software all the time. Also the production line you speak of exists in Agile Software too: Customer->Programmer->Tester-> Evaluate product (working code) and loop. Which is repeated again and again in small cycles (iterations) until the customer is happy with what he has got. Fashion works in a similar way too (iterative and incremental), so does Journalism and most other creative activities. BTW. Building great teams is nothing mystical, it just means having a people focus and putting people first. Paul.
  69. The tradgedy of "or"[ Go to top ]

    Paul,
    If their people weren’t any good, then obviously by definition they didn’t have "good Agile people".
    How do you find "good agile people?" The same person can be an outstanding performer on one project and a complete dud on another.
    (The Strategist) can make a better decision at 10,00 feet with no appreciation of the actual circumstance on the ground, then a team of intelligent individuals (notice, I say team) doing the job day to day.
    How can the boots on the ground make a good decision when all they see is what is immediately around them? A large enterprise needs people surveying the enterprise and making decisions from a high level. I'm not saying that all of the people who do this are particularly good at it. Many just push their favorite technology from their favorite vendor.
    I would like to think that suitable supervision and oversight existed so that a junior person wasn't left hung out to dry (pair programming anyone?). BTW, why is someone who “doesn’t know what he is doing” being asked to make database changes?
    Because "knowing what you're doing" is context sensitive, and determining both the competency of the person and the context simultaneously is very difficult.
    My point is that these are all people issues. The success of a development organisation comes down to its people and teams.
    Remove the word "development" and you have a very accurate statement that can be made about any organisation at any level in any business.
    The fundamental problem with agile methodologies is that they essentially advocate reverting to the original "wild west" type development model without addressing any of the problems that caused so many organizations to move away from it. So on one side of the debate you have "developers need freedom! Dynamic languages, fluid organizations, fluid requirements, no rules." On the other side you have "Developers need structure! Structured, staticly typed languages, fully documented requirements and design, rigorous process definition." Of course both extremes are equally ridiculus, and neither address the fundamental challenges of managing a software development project.
  70. Re: Ok, sure I'll stop now...[ Go to top ]

    heh...that's what I was thinking ;) either that or have factory factory builder factories generate the necessary sql =p
    >Here is a dumb question. What happens if you work at a company where developers are not allowed to run SQL and absolutely have to go through modeling with a Modeler and then wait for the modeler to talk to the DBA. The DBA then creates the tables. Once that is done, the developers have to write stored procs?


    In this scenario I don't think the question is RoR vs Java. I think it's time to ask yourself if it's time for another job?
  71. Re: Ok, sure I'll stop now...[ Go to top ]

    >Here is a dumb question. What happens if you work at a company where developers are not allowed to run SQL and absolutely have to go through modeling with a Modeler and then wait for the modeler to talk to the DBA. The DBA then creates the tables. Once that is done, the developers have to write stored procs?


    In this scenario I don't think the question is RoR vs Java. I think it's time to ask yourself if it's time for another job?
    .. which answer neatly summarizes the difference between RoR and Java, or at least their respective developers. Kit