On Thu, Sep 13, 2012 at 2:04 PM, Manfred Moser <[email protected]> wrote:
> On Wed, September 12, 2012 6:06 pm, Chris Graham wrote: > > On Wed, Sep 12, 2012 at 9:46 PM, Anders Hammar <[email protected]> > wrote: > > > >> I fully agree with you and I'm actually of the opinion that the Java > >> community has a responsibility to provide enough reasons for those on > >> older Java platforms to upgrade. But as long as we provide libraries > >> > > > > Simple. > > > > Two reasons actually. > > > > Without going off on an essay about the psychology of developers and > being > > obsessed with "shiny new things" (and a Dev centric view of the world)... > > > > 1. Cost. > > > > 2. Especially in the corporate world, they are far more concerned with > > function rather than form (ie the underlying technology). In short, if it > > works, leave it. Which also relates to #1. > > > > Case in point: My current project is a multi million dollar one that is > > *finally* moving from 5-7 YO tech to the newest stack. Partly due to the > > support issues, but mostly due to the cost of support of the older > > versions; it's finally become cheaper to upgrade than to continue paying > > the huge support costs. > > > > But my basic point is, that the act of upgrading large systems is not a > > cheap one, so it is NOT done lightly. > > I think that the cost is only so high because companies keep waiting until > it is too painful. If you constantly keep upgrading a bit here and there > and stay up to date with your operating systems, runtime environments, > browsers and client site frameworks and so on you would actually be able > to save a LOT of money in the long run. But you would have to constantly > invest rather than waiting with no investment until things fall apart and > then being forced to large costly upgrades. > > When a release has to move through 15 environments before it gets to prod (think large government project), and various change control boards etc, nothing is easy or cheap. And that is just for a release of code that we write. Updating the underlying technology stack is not a simple or cheap exercise. It's a matter of scale. Smaller, more self contained projects may indeed be able to take the faster route that you suggest. But it is always a matter of *business* risk, not *developer* led changes. > So it is mostly short sighted management and an absence of real technology > leadership in organizations causing this problem imho. And forcing the > I could not disagree with you more. And, in a strange way, you're made the very point that I'm trying to get across. What you've said there is a very developer centric view. Which is putting the technology ahead of the business. It is the business needs that should be dictating the technology; not the other way around. -Chris > pain to stay on old stuff higher (like Oracle is doing with deprecating > Java 6 earlier) is actually a good thing. > > imho Maven 2 should have long been deprecated and removed from the > downloads pages.. > > just my 2c though ;-) > > manfred > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
