Living on the cutting edge is fun. Until the day before the deadline your brand new webframework falls apart and both developers who answer all the questions in the forums and the mailing list are on vacation. Thats when you cut your self and start bleeding. Badly.

Using old technology isn't safe either. Have you lately tried to find a strong motivated developer for Powerbuilder? Visual Basic 6? Eclipse 3.2.2? You probably had a hard time. So the question arises: How close to the cutting edge should you be? As Stefan Tilkov probably would say: The answer is 'It depends'.

It depends on the size of the project:

• Is it small and not important, i.e. it doesn't matter if it takes longer than anticipated: Move close to the edge. This is a great chance for trying new stuff. But limit yourself to only a few new things. Otherwise the time for learning the new technology will make your small project long and painful.
• Is it small and important: Use the good old stuff. No experiments. The risk is to high, the payoff for new stuff not existing.
• Large projects: Large projects should allow for some experimentation at the beginning. Most of the time new stuff gets forced in these projects from outside sources anyway. Due to the long duration it pays of to invest some time into researching new ways of doing stuff.

If you do some research and experimentation great, but do it at the start of the project. As the project proceeds the technology stack should become more stable, until it is basically frozen.

In the projects described above most of the time teams seem to be able to find a reasonable compromise between boring old stuff and the cutting edge. But there is another kind of project where companies fail over and over again to apply sound judgment: Products. Products aren't real projects, they don't have an end. At least in the wishful thinking of the managers product sales never end. But this also applies on development. When you want to keep you competitive advantage over other products, you have to keep developing your product, as long as possible. Here the start of the product doesn't matter so much, but what is really important: stay current. You can't stop introducing new ideas and technologies. Moving from Java 1.5 to Java 1.6 shouldn't be so bad, but moving from Java 1.4 or even 1.3 to 1.6 means you'll have to rip out lots of your infrastructure as well. This can easily kill a product (and the attached company). When a new version of a technology you use becomes available. Let it settle for some time, maybe a year, but then adopt it. If your webframework goes out of fashion this isn't only a question of fashion. It is a question of getting support. Support in form  of payed support, answers in forums, plugins for IDEs and so on. So you have to find a way to migrate smoothly as technology changes.

If you don't do this the only option left after a couple of years will be a complete rewrite of the system or a migration that is equally hurting. And this means months, or years of stagnation on the feature front. Your customers won't like that and won't pay it.