Weblogs Forum - Java EE: "Java Ever Evolving"

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Java EE: "Java Ever Evolving"

24 replies on 2 pages. Most recent reply: Jul 12, 2006 3:20 PM by Alper Akture

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 24 replies on 2 pages [ « | 1 2 ]

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Java EE: "Java Ever Evolving"

Posted: Jun 29, 2006 1:55 AM

Reply

Advertisement

> ...the effect of causing organizations and people to
> artificially attempt to stay on the bleeding edge.

That's a curious phrase. What does it mean?

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Java EE: "Java Ever Evolving"

Posted: Jun 29, 2006 2:30 PM

Reply

> > The technology itself is advancing pretty rapidly. So
> > while an architecture from 2003 is still working well
> > today, and the code still probably compiles and runs with
> > newer versions of the JEE specs, app server and various
> > other libraries, its architecture is not "contemporary".

> Wow, 3 years from hype to legacy! If that is "nothing of
> substance" then I'd like to know what a substantial
> problem for Enterprise computing should be. Is it the
> permanent migration from legacy frameworks to
> "contemporary" frameworks?

Software is legacy the moment the first line of code is written. It's a fact that most of us got used to years ago.

Legacy is not a bad thing, and from a business point of view it's a good thing as long as there is a clear support path for the expected duration of the application and beyond.

Peace,

Cameron Purdy
http://tangosol.com/

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Java EE: "Java Ever Evolving"

Posted: Jun 29, 2006 3:12 PM

Reply

> > ...the effect of causing organizations and people to
> > artificially attempt to stay on the bleeding edge.

> That's a curious phrase. What does it mean?

Perhaps I'm a tad cynical ;-), but many of us delude ourselves into believing that we are staying on the bleeding edge by learning some new over-hyped technologies, products, open source libraries, extreme agile methodologies or other gobbledygook. It makes us feel more comfortable with the various technological ruts that we've fallen into. For companies, the same approach is used to help developers convince themselves to come work for a company (or not jump ship to do something interesting elsewhere).

In the end, the "bleeding edgeness" is as much a beauty contest as any other in our culture. (My iPod hard drive is bigger than yours. My car is faster. My house is bigger. I code with Ruby. etc.)

My opinion (worth about what you've paid for it) is that to be truly unique in this industry, all you have to do is listen well, follow through and really solve the customers' or employer's problems, because that seems to be the thing that we as software practitioners always seem to forget in the rush to stay on the bleeding edge.

FWIW ;-)

Peace,

Cameron Purdy
http://www.tangosol.com/

Roland Pibinger

Posts: 93
Nickname: rp123
Registered: Jan, 2006

Re: Java EE: "Java Ever Evolving"

Posted: Jun 30, 2006 12:10 PM

Reply

> Software is legacy the moment the first line of code is
> written. It's a fact that most of us got used to years
> ago.

Strange point of view ...

Andy Dent

Posts: 165
Nickname: andydent
Registered: Nov, 2005

Re: Java EE: "Java Ever Evolving"

Posted: Jun 30, 2006 7:03 PM

Reply

Some code becomes legacy code instantly, not all.

Read Michael Feathers' Working Effectively with Legacy Code - a classic which I am now recommending to people as the book they should read before Fowler's Refactoring (Funny isn't it that both authors are here on Artima!)

http://www.amazon.com/exec/obidos/ASIN/0131177052/andydentsrecomme

I knew that Erik had just started a consulting gig with a new team, so I asked him, "How are they doing?" He said, "They're writing legacy code, man."

Roland Pibinger

Posts: 93
Nickname: rp123
Registered: Jan, 2006

Re: Java EE: "Java Ever Evolving"

Posted: Jul 1, 2006 2:29 AM

Reply

> Some code becomes legacy code instantly, not all.
> Read Michael Feathers' Working Effectively with Legacy
> Code - a classic which I am now recommending to people
> as the book they should read before Fowler's
> Refactoring (Funny isn't it that both authors are
> here on Artima!)
> http://www.amazon.com/exec/obidos/ASIN/0131177052/andydents
> recomme
> I knew that Erik had just started a consulting gig with
> a new team, so I asked him, "How are they doing?" He said,
> "They're writing legacy code, man."

Thanks (I already have both books). The goal obviously is to avoid writing legacy code from the start. That means you need a basic understanding of your software environment and not just grab the 'framework of the week'.

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Java EE: "Java Ever Evolving"

Posted: Jul 3, 2006 3:02 AM

Reply

> Some code becomes legacy code instantly, not all.
>
> Read Michael Feathers' Working Effectively with Legacy
> Code - a classic which I am now recommending to people
> as the book they should read before Fowler's
> Refactoring (Funny isn't it that both authors are
> here on Artima!)

Of course, by the strict definition of legacy code, most code is not legacy the moment it is written, since the origin of the term has to do with hardware drivers for no-longer-supported devices.

I am quite amused by the responses, though, as people attempt to convince themselves that they do not write "legacy code".

Peace.

Roland Pibinger

Posts: 93
Nickname: rp123
Registered: Jan, 2006

Re: Java EE: "Java Ever Evolving"

Posted: Jul 3, 2006 5:06 AM

Reply

> Of course, by the strict definition of legacy code, most
> code is not legacy the moment it is written, since the
> origin of the term has to do with hardware drivers for
> no-longer-supported devices.
> I am quite amused by the responses, though, as people
> attempt to convince themselves that they do not write
> "legacy code".

An application becomes 'legacy' when it has reachend the end of its lifecycle, ie. when it does not operate or is not maintainable (extendable, changeable, testable, ...) with reasonable cost any more. OTOH, a new application should form a usable, stable and predictable basis for further developement. I guess you just use the word 'legacy' in your own specific meaning.

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Java EE: "Java Ever Evolving"

Posted: Jul 3, 2006 3:23 PM

Reply

Roland,

My thinking (potentially flawed) is thus:

Software, like hardware used to be, is a target for integration. We used to call these "drivers" with hardware, and now we call them "APIs" and "schemas" and "components" and "libraries" and "services". When we begin to realize (in code form) the designs that we conceive in our minds eye, we begin to set those designs in stone, so -- at least in "enterprise software" -- the integration points become hardened by their existence (i.e. by the likelihood of their use). Similarly, because of the complexity of integration, the behavior of the application becomes a requirement once integration has occurred.

(Cue Shakespeare: Oh what a twisted web we weave, when integration we achieve.)

Obviously, the concepts of loose coupling and service oriented architecture are intended to mitigate these concerns, but they only mitigate -- not eliminate. (At least in my experience.)

Thus, it is not so far off to suggest that a design, once realized in code, is (in its own way) a legacy system.

While I would not attempt to defend it to the letter of the law, I certainly have no problem defending it in the abstract (the spirit of the law ;-)

Peace.

Alper Akture

Posts: 2
Nickname: aakture
Registered: Jul, 2006

Off Topic

Posted: Jul 12, 2006 3:20 PM

Reply

Sean, did you used to work at Rockwell back in the mid 80's? If so, could you contact me? aakture at hotmail. Thanks.

Flat View: This topic has 24 replies on 2 pages [ « | 1 2 ]

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use