Do we forget the lean times?

I remember the lean times. I was once without a job for nine months, and I was working a part-time job on and off while looking for an IT job after finishing ArsDigita University. Remembering those times make you a little scared, make you want to save money instead of spend it, make you want to have an escape route out of your current situation in case it comes crashing down.

I remember when I started learning Java. It was 1999. Applets were the only thing that we could get to work on the web, and maybe JSP and Servlets were starting to get there for server-side programming. The only other thing that was out there was the Enterprise-level programming of EJB, which confused the majority of us out there and made us want to do something else.

So in 2002, someone introduced me to Struts, and it looked like a breath of fresh air. Since then, other programmers have been quietly (or not so quietly) churning out tool after tool that we can use. Hibernate. Velocity. Tapestry. Grinder. DbUnit. The list keeps unfolding for us.

A recent post entitled, How to use Java at a Startup, puts forth the argument that Java is all you need. He does point out, however, that the overchoice is a double edged sword:

There are so many options available that it is possible to get stuck in analysis paralysis while you look for that perfect fit. I do this all the time. In my quest for the perfectly elegant solution I get myself perfectly puzzled. It’s also possible to pick technologies that just don’t work together very well. I find that the best way to narrow down the list is to make your best guess and then prototype the technologies to see if they meet your need. Remember, a good plan violently executed today will be better than a perfect plan executed tomorrow. That said, you do need criteria for evaluating Open Source projects for use in a startup.

We had some lean times with Java; maybe that's what spurred all the growth of frameworks and the over-choice we have today. Now that we've come through the lean period though, do we make that memory drive what Java will be tomorrow? Will our memory of the absence of good features and the ability to execute quickly change how we develop Java 6?

Again, I am disappointing by putting forth more questions than answers, but there is a point to all this. How do you stick to your guns with one part of the technology when there is new, promising technology that claims to be a 'silver bullet' that will take its place? How do you know when to stop moving from new framework to new framework?