J2EE and developer productivity

Discussion in 'Java' started by toxa26@gmail.com, Aug 2, 2005.

  1. Guest

    I would like to bring up the fact that, as a professional java
    developer, I find today's development environment to be quite
    unproductive. Even with all the build/deploy stages scripted in ant,
    it still takes minutes for me to be able to run my code. For smaller
    apps all this j2ee redeploy cycle might be acceptable, but I'm sure
    many of you will agree, debugging serious j2ee projects is simply
    annoying. If anyone knows how to alleviate this redeployment lag,
    please post!
    , Aug 2, 2005
    #1
    1. Advertising

  2. jan V Guest

    > I would like to bring up the fact that, as a professional java
    > developer, I find today's development environment to be quite
    > unproductive. Even with all the build/deploy stages scripted in ant,
    > it still takes minutes for me to be able to run my code. For smaller
    > apps all this j2ee redeploy cycle might be acceptable, but I'm sure
    > many of you will agree, debugging serious j2ee projects is simply
    > annoying. If anyone knows how to alleviate this redeployment lag,
    > please post!


    I've got zero J2EE experience, but I recognize the symptom. The
    edit/compile/test cycle in non-J2EE (e.g. J2SE) environments can suffer from
    the same problem.

    My partial solution is to work on small modules that can be run and tested
    without the complete system, thus avoiding wasting minutes in expensive and
    repetitive "booting" of the system.

    With the levels of complexity we're asked to tackle these days, it's *so*
    easy to fall asleep during development and "go with the flow".. and forget
    that you can actually stop and think through these issues and come up with
    surprisingly simple solutions. There's way too much "doing" and not enough
    "let's take a few steps back here, and think" in our industry.
    jan V, Aug 2, 2005
    #2
    1. Advertising

  3. barilla Guest

    hello,

    i work with eclipse, xdoclet and ant.
    i rebuild/redeploy all the project each time,
    to keep it simple.

    i have 2 final ant tasks :

    - 1 for regenerating all files with xdoclet.
    i use that to update the workbench
    when i create a new EJB or modify entity fields.

    - 1 for regerating, compiling, deploying ...


    1 click on a specific ant task, my 400 java files
    are generated fwith xdoclet, compiled, archived
    in jars/ears files.
    jboss automatically detects the new .ear file
    and a few seconds later second to deploy in jboss.

    so 1mn30 to do that on a aging athlon XP 2200 +ide drive
    means something like 40sec on a recent amd64 system.

    for me 40s to build/deploy is not a big problem because
    it takes a few minutes to test.
    is it a problem for you ?

    note that i could have splited the project
    in subprojects to reduce build/deploy time, ...
    barilla, Aug 2, 2005
    #3
  4. jan V Guest

    > for me 40s to build/deploy is not a big problem because
    > it takes a few minutes to test.
    > is it a problem for you ?
    >
    > note that i could have splited the project
    > in subprojects to reduce build/deploy time, ...


    <Humor>
    Hey, tell us all who you work for, because I'd love to work for a company
    that lets me squander time like this ;-) I like a relaxed working atmosphere
    (gives me more time to think).
    </Humor>
    jan V, Aug 2, 2005
    #4
  5. barilla Guest

    jan V wrote:
    > <Humor>
    > Hey, tell us all who you work for, because I'd love to work for a company
    > that lets me squander time like this ;-) I like a relaxed working atmosphere
    > (gives me more time to think).
    > </Humor>


    i have to admit i'm french, perhaps it helps.
    i've just heard recently that we have the 2nd best
    working rentability in the world (after belgium).

    but 40sec a few times a day is not that much.
    even if i had a 0sec build/deploy time,
    my working day would not be much different ... ?

    the good point with eclipse and code generation, is that
    you don't have to rebuild to see if your code is well written.
    logic problems remains, but i have few.
    gui/swing problems are the most frequent ones,
    but i don't have to redeploy the server side to test that part.
    barilla, Aug 2, 2005
    #5
  6. jan V Guest

    > > <Humor>
    > > Hey, tell us all who you work for, because I'd love to work for a

    company
    > > that lets me squander time like this ;-) I like a relaxed working

    atmosphere
    > > (gives me more time to think).
    > > </Humor>

    >
    > i have to admit i'm french, perhaps it helps.
    > i've just heard recently that we have the 2nd best
    > working rentability in the world (after belgium).


    Ha, that's no good then, because I'm Belgian :))

    > but 40sec a few times a day is not that much.
    > even if i had a 0sec build/deploy time,
    > my working day would not be much different ... ?


    Hmmm.. at my last job we needed to build probably 20-50 times a day, so then
    the costs of delays mount.

    Then again with this last employer we had to build that frequently because
    they:

    - did not design things properly, and instead "evolved" their systems (while
    sucking on their thumbs)

    - wanted to see you coding, coding, coding, coding, without ever taking the
    time to work out precisely what is needed (requirements? analysis? design?
    nah... just code, code, code)
    jan V, Aug 2, 2005
    #6
  7. Bryce Guest

    On 2 Aug 2005 08:36:33 -0700, wrote:

    >I would like to bring up the fact that, as a professional java
    >developer, I find today's development environment to be quite
    >unproductive. Even with all the build/deploy stages scripted in ant,
    >it still takes minutes for me to be able to run my code. For smaller
    >apps all this j2ee redeploy cycle might be acceptable, but I'm sure
    >many of you will agree, debugging serious j2ee projects is simply
    >annoying. If anyone knows how to alleviate this redeployment lag,
    >please post!


    Spring Framework:
    www.springframework.org

    You develop using the Spring way of doing things, it makes your code
    easy to test without having to deploy it. Makes my J2EE
    development/build/deploy stages fast and enjoyable.

    YMMV

    --
    now with more cowbell
    Bryce, Aug 2, 2005
    #7
  8. . Guest

    On Tue, 2 Aug 2005, jan V wrote:

    > > > <Humor> Hey, tell us all who you work for, because I'd love to work
    > > > for a company that lets me squander time like this ;-) I like a
    > > > relaxed working atmosphere (gives me more time to think).
    > > > </Humor>

    > >
    > > i have to admit i'm french, perhaps it helps.
    > > i've just heard recently that we have the 2nd best
    > > working rentability in the world (after belgium).

    >
    > Ha, that's no good then, because I'm Belgian :))
    >
    > > but 40sec a few times a day is not that much.
    > > even if i had a 0sec build/deploy time,
    > > my working day would not be much different ... ?

    >
    > Hmmm.. at my last job we needed to build probably 20-50 times a day, so then
    > the costs of delays mount.
    >
    > Then again with this last employer we had to build that frequently because
    > they:
    >
    > - did not design things properly, and instead "evolved" their systems (while
    > sucking on their thumbs)
    >
    > - wanted to see you coding, coding, coding, coding, without ever taking the
    > time to work out precisely what is needed (requirements? analysis? design?
    > nah... just code, code, code)


    I've seen this philosophy a lot. If you are doing something and it is not
    working, do it faster.

    It is kind of sad. I've been watching the industry for 20 years and it
    seems like the following is happening:

    Company A takes it time and produces a good product in 8 months. Company M
    follows the code, code, code philosophy and produces a poor product in 6
    months. Company M has good marketing and the customer will take a few
    months just to realize the Company M software is flakey, at best. They
    will complain to Company M who will have a patch (also created with the
    code, code, code philosophy). Company A will ship their product but few
    people will buy it because they spent more money on hiring good
    programmers, creating an efficient development process, less on marketing
    and they got to market 2 months late.

    I believe this is why it is getting harder and harder to find a job at a
    company like Company A. The Company M of the world survive because they
    have found that balance of being bad enough to save a buck but good enough
    the customer doesn't completely walk away.

    --
    Send e-mail to: darrell dot grainger at utoronto dot ca
    ., Aug 3, 2005
    #8
  9. jan V Guest

    > > - wanted to see you coding, coding, coding, coding, without ever taking
    the
    > > time to work out precisely what is needed (requirements? analysis?

    design?
    > > nah... just code, code, code)

    >
    > I've seen this philosophy a lot. If you are doing something and it is not
    > working, do it faster.
    >
    > It is kind of sad. I've been watching the industry for 20 years and it
    > seems like the following is happening:
    >
    > Company A takes it time and produces a good product in 8 months. Company M
    > follows the code, code, code philosophy and produces a poor product in 6
    > months. Company M has good marketing and the customer will take a few
    > months just to realize the Company M software is flakey, at best. They
    > will complain to Company M who will have a patch (also created with the
    > code, code, code philosophy). Company A will ship their product but few
    > people will buy it because they spent more money on hiring good
    > programmers, creating an efficient development process, less on marketing
    > and they got to market 2 months late.
    >
    > I believe this is why it is getting harder and harder to find a job at a
    > company like Company A. The Company M of the world survive because they
    > have found that balance of being bad enough to save a buck but good enough
    > the customer doesn't completely walk away.


    Your analysis is spot on, and I've also come to the same conclusion. I've
    also been in the industry for nearly 20 years now, and I just despair at the
    lack of proper software engineering in the vast majority of companies. For
    me it's very problematic because I just refuse to do it the quick-and-dirty
    way... it makes finding the A companies an almost intolerably depressing
    exercise... at interviews I have to bend over backwards to use every ounce
    of diplomacy in me, otherwise I come across as arrogant, when it fact all
    I'm after is doing things as best as I can, as professionally as I can...
    but the majority of companies run a mile when they hear that, because they
    know too well that they rely on cutting corners ALL THE TIME to get their
    "products" out of the door "yesterday". It's a very, very sad industry if
    you ask me.
    jan V, Aug 3, 2005
    #9
  10. Wibble Guest

    jan V wrote:
    >>>- wanted to see you coding, coding, coding, coding, without ever taking

    >
    > the
    >
    >>>time to work out precisely what is needed (requirements? analysis?

    >
    > design?
    >
    >>>nah... just code, code, code)

    >>
    >>I've seen this philosophy a lot. If you are doing something and it is not
    >>working, do it faster.
    >>
    >>It is kind of sad. I've been watching the industry for 20 years and it
    >>seems like the following is happening:
    >>
    >>Company A takes it time and produces a good product in 8 months. Company M
    >>follows the code, code, code philosophy and produces a poor product in 6
    >>months. Company M has good marketing and the customer will take a few
    >>months just to realize the Company M software is flakey, at best. They
    >>will complain to Company M who will have a patch (also created with the
    >>code, code, code philosophy). Company A will ship their product but few
    >>people will buy it because they spent more money on hiring good
    >>programmers, creating an efficient development process, less on marketing
    >>and they got to market 2 months late.
    >>
    >>I believe this is why it is getting harder and harder to find a job at a
    >>company like Company A. The Company M of the world survive because they
    >>have found that balance of being bad enough to save a buck but good enough
    >>the customer doesn't completely walk away.

    >
    >
    > Your analysis is spot on, and I've also come to the same conclusion. I've
    > also been in the industry for nearly 20 years now, and I just despair at the
    > lack of proper software engineering in the vast majority of companies. For
    > me it's very problematic because I just refuse to do it the quick-and-dirty
    > way... it makes finding the A companies an almost intolerably depressing
    > exercise... at interviews I have to bend over backwards to use every ounce
    > of diplomacy in me, otherwise I come across as arrogant, when it fact all
    > I'm after is doing things as best as I can, as professionally as I can...
    > but the majority of companies run a mile when they hear that, because they
    > know too well that they rely on cutting corners ALL THE TIME to get their
    > "products" out of the door "yesterday". It's a very, very sad industry if
    > you ask me.
    >
    >

    I'm a big fan of the 'right way' but the goal of every project is to
    make money. Time to market is more valuable than smiles. The ticket is
    to optimize time by improving quality, like by writing unit tests. Keep
    in mind that artists are mostly starving.
    Wibble, Aug 9, 2005
    #10
  11. kjc Guest

    Wibble wrote:
    > jan V wrote:
    >
    >>>> - wanted to see you coding, coding, coding, coding, without ever taking

    >>
    >>
    >> the
    >>
    >>>> time to work out precisely what is needed (requirements? analysis?

    >>
    >>
    >> design?
    >>
    >>>> nah... just code, code, code)
    >>>
    >>>
    >>> I've seen this philosophy a lot. If you are doing something and it is
    >>> not
    >>> working, do it faster.
    >>>
    >>> It is kind of sad. I've been watching the industry for 20 years and it
    >>> seems like the following is happening:
    >>>
    >>> Company A takes it time and produces a good product in 8 months.
    >>> Company M
    >>> follows the code, code, code philosophy and produces a poor product in 6
    >>> months. Company M has good marketing and the customer will take a few
    >>> months just to realize the Company M software is flakey, at best. They
    >>> will complain to Company M who will have a patch (also created with the
    >>> code, code, code philosophy). Company A will ship their product but few
    >>> people will buy it because they spent more money on hiring good
    >>> programmers, creating an efficient development process, less on
    >>> marketing
    >>> and they got to market 2 months late.
    >>>
    >>> I believe this is why it is getting harder and harder to find a job at a
    >>> company like Company A. The Company M of the world survive because they
    >>> have found that balance of being bad enough to save a buck but good
    >>> enough
    >>> the customer doesn't completely walk away.

    >>
    >>
    >>
    >> Your analysis is spot on, and I've also come to the same conclusion. I've
    >> also been in the industry for nearly 20 years now, and I just despair
    >> at the
    >> lack of proper software engineering in the vast majority of companies.
    >> For
    >> me it's very problematic because I just refuse to do it the
    >> quick-and-dirty
    >> way... it makes finding the A companies an almost intolerably depressing
    >> exercise... at interviews I have to bend over backwards to use every
    >> ounce
    >> of diplomacy in me, otherwise I come across as arrogant, when it fact all
    >> I'm after is doing things as best as I can, as professionally as I can...
    >> but the majority of companies run a mile when they hear that, because
    >> they
    >> know too well that they rely on cutting corners ALL THE TIME to get their
    >> "products" out of the door "yesterday". It's a very, very sad industry if
    >> you ask me.
    >>
    >>

    > I'm a big fan of the 'right way' but the goal of every project is to
    > make money. Time to market is more valuable than smiles. The ticket is
    > to optimize time by improving quality, like by writing unit tests. Keep
    > in mind that artists are mostly starving.


    "Keep in mind that artists are mostly starving."
    Is a VERY good wake-up call and reminder of where the industry has headed.
    kjc, Aug 9, 2005
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Martin Rosén-Lidholm

    Productivity: WebForms vs. WinForms

    Martin Rosén-Lidholm, Jun 21, 2004, in forum: ASP .Net
    Replies:
    20
    Views:
    2,867
    Rob Nicholson
    Jul 8, 2004
  2. Adriano Monteiro
    Replies:
    7
    Views:
    285
    Scott David Daniels
    Sep 24, 2005
  3. Claudio Grondi

    Productivity and Quality of IDE

    Claudio Grondi, Jan 2, 2006, in forum: Python
    Replies:
    4
    Views:
    285
    James
    Jan 3, 2006
  4. Paul Rubin
    Replies:
    8
    Views:
    262
    Steve Holden
    Sep 28, 2006
  5. Behrang Saeedzadeh
    Replies:
    2
    Views:
    147
    Chad Perrin
    Apr 14, 2007
Loading...

Share This Page