«

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 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.

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, ...

> 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 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.

> > <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)

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

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

> > - 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 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.