How quickly should I adopt new technology, i.e. new .NET versions, new VS versions, etc.?

Question

I'm never sure how quickly I should be adopting new technology. I often just don't until there is a need from a client, or I have a new project that makes it easy to just start with a new version.

How often do others adopt new technology?

Is there a reason to jump right in?

Is there a good reason not to?

Are there some good rules of thumb, or guidelines? Approaches?

Answer 1

I guess my "rule of thumb" is to adopt the technology when the following are true:

1. I need the functionality the technology provides. I don't want to use it just to be using it.
2. I am confident the technology is stable enough to include in the project in which I plan to use it.
3. A reasonable level of support is available through Google searches, StackOverflow, or other means.
4. I am confident the technology will enhance my productivity, not impede it.

Answer 2

I never rush to adopt any new technology but that does not prevent me from firing off a VM, install it there and play with it so I can learn what it is about. There is no reason to jump right in and use the "new thing" straight into a product that some customer is paying for before you have a reasonable understanding of its benefits and drawbacks.

So I guess the rule of thumb is, keep yourself informed, play with the new thing as much as your time allows and when the time comes (if it does) use it on a real life product. For example, I never used WF in any project but I have a fairly good understanding of it if I decide to use.

Answer 3

There is a big difference between a new version, and a new technology.

When a new version comes out, now is the time to upgrade. If you find yourself using a 5 year old version of a framework, you will feel the pain of compatibility issues with plugins, and the amount of change might make the upgrade seem ominous.

As for new technologies, it just depends. You need to find the happy middle ground between always spending your time learning a new tool, and getting less done because you are using outdated technologies.

Some reasons to jump right in:

1. You are a consultant, and will need to be comfortable with a variety of tools and technologies.
2. You are new in IT, and the new technology will expose you to different ways of thinking.
3. The technology claims to solve a problem that is a particular pain point in your current work.
4. The technology seems really fun.

If none of these are the case, then carry on with your work. And you can always fill your time learning and practicing the timeless principles of computer science and software engineering.

Answer 4

To me, "adopting" a new technology is never done by the throw of a switch. I will give it a try as early as possible in a development environment, but not use it in a production system until I'm confident about its stability. That way, I know right away what my migration issues will be and the potential benefits, and can plan enough time to switch in a controlled manner. Every once in a while, I'm pleasantly surprised that it works right away. Usually it takes a few trial migrations to convince me it's ready.

Answer 5

There's a lower bound and an upper bound.

How often do others adopt new technology?

Not too early. Wait for others to find bugs.

Not too late. After too long support will end.

Is there a reason to jump right in?

If you need the feature, yes.

Otherwise, it pays to wait for a maintenance release.

Is there a good reason not to?

Yes. You may be first to find new bugs. That can be painful.

Are there some good rules of thumb, or guidelines? Approaches?

Not too early. Wait for others to find the obvious bugs.

Not too late. After too long support will end.

Answer 6

What do you mean by "adopting"? Learning how to use it, building toy projects: as soon as you think you may be needing it soon. Using it in production code: as soon as the benefits definitely outweigh the risks.