SQLServerCentral Editorial

Early Adopters

,

Today we have a guest editorial from Andy Warren as Steve Jones is out of town.

Awhile back I read a comment that categorized Microsoft MVP’s as early adopters but characterized that as a negative point, something I noted to think about more as I had time. Are all MVP’s early adopters? Is early adoption of new features a bad thing? Going further, what are good reasons in favor or against early adoption?

There are about 270 SQL Server MVP’s at present. From what I’ve seen over the years their interest in new features in not so much about ‘latest and greatest’ as it is wanting solutions – or better solutions – to problems they see over and over. They try to achieve that by providing private feedback to Microsoft and public feedback via blogs and Connect. If they end up being thrilled with an improvement that makes something work better or take less effort it’s hard for me to see that as more than common sense and love of the craft. That’s not to say that some MVP’s aren’t early adopters, of course they are. The only way to see what works and be able to help clients and employers pick from a complex range of options is to use it.

What are the risks and benefits of early adoption? That’s worth a lot more than a paragraph. Perhaps the biggest risk (I see us as being experienced at managing the risk of version upgrades) is that we bet on a feature that doesn’t scale or ends up being deprecated – anyone remember English Query and Notification Services – but that is rare.  The biggest benefit is almost always that it lets a business make some kind of leap that the earlier version made hard or impossible. Not all of us need to early adopt, but some of us do, and the reasons are usually very clear and worth the risk of moving to the leading edge for a few months.

For those of who don’t need new and improved feature X we sit back and observe while the early adopters learn what works well, what works ok, and what doesn’t work very well. The lessons learned are out there for when we do need feature X and that feedback almost always makes the next iteration of the feature better. Look at the steady list of improvements to Availability Groups as a great example of that cycle.

I’m not advocating that we all move to SQL vNext on release day, nor am I advocating that we stay on SQL 2005 (or 2000, or 7) because ‘it works’. It doesn’t have to be all or none when it comes to features or versions. I don’t feel bad about skipping a release nor am I reluctant to point out reasons why a new version/feature would benefit the business. I do recognize though that unless someone tries a feature and pushes it to the max or beyond that it won’t get better and may not be good enough when I finally need it.

I’m curious to hear your opinions on early adoption. As you look back at your experience doing it (or not) has it made a noticeable impact on the business or on your career?

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating