On the chance of sounding like a reactionary old fart I'm going to post a few more thoughts on this obviously charged topic started originally by Michael Earl.

Steve Black as always makes a good point that we're being force fed new features that we really don't need. Not only that but really we're being forced into a new paradigm every few years and as developers there's a continual process of relearning going on.

I'm torn on both sides of the argument. I agree with Steve's point but at the same time I also enjoy part of that aspect as learning is part of the job of software developement that hold the biggest challenge.

Let's look at the issue from the perspective that Steve points out.

Look around you at other environments. If you're a C++ programmer or a Java Programmer your environment hasn't changed much over the last years. Things are pretty stable. There's a new dose of new enterprise features here and there but overall the pace of change is gradual and uh, sane...

Now compare with the Microsoft/Windows platform. .Net came out about a year about with another year before in a public beta. .Net was a complete overhaul as in throw away everything you had before it and start over. In another year Whidbey will come along but thankfully that will be an evolutionary change. Then another year and Longhorn/WinFx will roll around and that no doubt be another major shift where you will have to throw out much of the code you already have.

This eternal merry go around shuffles around a lot of people working in this industry. Look at how many top of the line people were left behind by the switch to .Net. A lot of people - especially a lot of the VB crowd - were very frustrated that their user friendly tool got turned into a high end Enterprise level development tool that doesn't care much about building end-user applications or one-of tools. They're not likely to come to the .Net party. A lot of developers working with other tools also aren't very likely to go there.

These major shifts take a toll on developers and although some people make the switch they put up alot of effort to do so. Going on multiples of these changeovers starts getting to be a drag as a lot of time and effort is spent on relearning what you already knew and re-writing code that you already had. And some people will just be too burned out to continue doing it over and over again 'just because'. The value proposition has to be there and with Microsoft it often isn't.

I can attest to this personally. I've worked for years with Visual FoxPro and still do. I had libraries for practically everything including easy access to Web Services, Web interfaces and flexible data driven engines and tools. A business object/data access layer. In making the switch to .Net I had to re-write A LOT of code that I already had and does essentially the same thing - just so I can be in the same position that I was in previously. Yes in the process I was able to throw out a lot of infrastructure stuff (the XML stuff is native, conversions, Web Services etc) so there's advantage in deferring some of this logic to the framework, but other stuff like the business object framework had to be rebuilt from scratch.

Now that I'm through that original phase of 'rebuilding my platform' I feel good about it and I am indeed more productive than I was before because the tools (especially ASP.Net and the Web Platform) are more productive. But to get there took close to a year of learning and rebuilding. Now, what do you think that will feel like if I have to do it again even in 2-3 years from now? It gets tiring writing the same code over and over again only to arrive at a starting point. Sure it doesn't take a year to get there to write a one off application, but if you build new stuff all the time having your framework code is the most important thing you can have as a developer.

The point here is that in order to become a good developer on a given platform and toolset requires time. You need to actually have time to use what you build, use in every day development and come up with tests and your own benchmarks and experience that puts the toolset into perspective.

When change is too frequent we never have the time to let the tools gel. That's not just the tools that Microsoft provides or even third party tools, but most importantly our own code libraries and patterns and design approaches. If you're constantly running around learning new stuff you don't have time to refine the stuff that's already in place.

If you look at the volume of Blogs and people posting you might get the impression that EVERYONE is already on to the next big thing, but the truth is more likely that these people just like you and me are doing the same release code stuff to earn their money. Article publishing, books, WebLogs and the general technical content that's published etc. really skew the view one gets of where the majority of this industry's focus is.

And I think this comes back exacltly the place where Michael's original article was coming from. The more we focus on the 'Now' (maybe read Eckhart Tolle's the 'Power of Now') the more productive we can all be even when the changes come around later on.