Early Adopters

  • Comments posted to this topic are about the item Early Adopters

  • My problem with early adoption is that the first version is not at all complete and that usually need to wait a cyle or two until you get all of the features that you need.

    A perfect example of this are memory-optimised tables in SQL Server 2014. With promises of between 10x and 30x improvement over disk-based tables, I realised that this was no ordinary upgrade from Microsoft, this has the promise to be the most significant change in the SQL Server engine since it started (although I started with v7).

    However, it came with a large numbers of gotchas (no Foreign Keys, the big improvements came with the memory-optimised SPs which didn't allow outer joins, etc.). It was great learning experience trying to fit the tables of one our schemas into a complete memory-optimised DB. It needed a lot of work-arounds. It may also be that it is actually a niche feature and that I expected way too much from it.

    SQL Server 2016 is coming out soon and most (if not all) of the problems are solved with this version. As soon as it commercially released, I shall fire up my 64GB server again and redo my initial migration. Is early adoption bad? Not at all. If you know what you want and if the new feature makes your life easier, then it is perfect. Just expect change.

  • I have been an early adopter of technologies at times but it has always been following an evaluation as to the immediate benefits as well as the medium term potential benefits. Other times evaluation has steered projects clear of early adoption. There have also been times when early adoption was not even evaluated.

    It is simply a situation to apply a variant of cost benefit analysis.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Well said, but the one thing I found absent from the discussion was the price/feature ratio (or price/improvement if you will), particularly nowadays with Microsoft's rather byzantine licensing structure. To wit: Do we really need to pull money from the budget this year to get shiny new feature X which turns out to be not all it was cracked up to be or wait it out a budget cycle or two until it matures? Or are there other improvements that make it worth the $$$ anyway?

    Certainly not the only consideration, but definitely a significant one.

    ____________
    Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.

  • I think there are maybe three types of MVPs: those who scout ahead exploring the latest version of SQL Server or how to push the product to it's limits, those selfless evangelists who go on the road and educate the masses on topics like best practices, and those who do heroic stuff behind the scenes like delving into internals and troubleshooting in public forums.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell (11/20/2015)


    I think there are maybe three types of MVPs: those who scout ahead exploring the latest version of SQL Server or how to push the product to it's limits, those selfless evangelists who go on the road and educate the masses on topics like best practices, and those who do heroic stuff behind the scenes like delving into internals and troubleshooting in public forums.

    I believe those to be independent and separate facets.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • I think early adoption is useful when it adds value to the business.

    The problems I have experienced with SS are always finding value in the product beyond being a database. For instance, T-SQL as a language has to change for SQL to be competitive, and features that allow surfacing data in an MVVM world I think the sql team could invent smoother ways of hooking up to javascript, node, and other net world mediums for quickly surfacing ways to managing data. PowerBI is an interesting tool, and I know the SQL team's mantra has always set clear boundaries on what is sql server and what isn't. But in a competitive world where open source PostGres is bouncing on the heels of what is SS, unless the team innovates on a level that gives the product value without question, the lifetime of the product may be seen.

    Just as html allows javascript language to be marked up within it's text, so shouldn't T-SQL have javascript markup or c# markup sections to facilitate logical processes without having to use sqlclr as an interface for these things.

    Thank you for reading,

    Joe

  • Someone has to be the early adopter. Today's so what was yesterday's OMG.

    Business is about calculated risks and a bit of a gamble. Low cost experimentation has to be the order of the day. You can be a lot braver with low cost technology and be more likely to succeed as a result.

    High cost experimentation could sink the company.

  • Gary Varga (11/20/2015)


    Eric M Russell (11/20/2015)


    I think there are maybe three types of MVPs: those who scout ahead exploring the latest version of SQL Server or how to push the product to it's limits, those selfless evangelists who go on the road and educate the masses on topics like best practices, and those who do heroic stuff behind the scenes like delving into internals and troubleshooting in public forums.

    I believe those to be independent and separate facets.

    Yes, some do all three. However, it's hard to consistently do one, when you have a 9 -5 day job.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell (11/20/2015)


    Gary Varga (11/20/2015)


    Eric M Russell (11/20/2015)


    I think there are maybe three types of MVPs: those who scout ahead exploring the latest version of SQL Server or how to push the product to it's limits, those selfless evangelists who go on the road and educate the masses on topics like best practices, and those who do heroic stuff behind the scenes like delving into internals and troubleshooting in public forums.

    I believe those to be independent and separate facets.

    Yes, some do all three. However, it's hard to consistently do one, when you have a 9 -5 day job.

    They're not VPs. They're MVPs!!! :smooooth:

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • There are no SQL Server MVPs anymore! We're Data Platform MVPs now!!

    Gerald Britton, Pluralsight courses

  • Early adoption really boils down to need vs risk.

    Unless you are a tech company you are most likely version driven by the vendor products you are utilizing.

    Another thing is that all too often we look at the technology first, obtain that, then seek what runs on that and will solve our issues. Rather than buying a solution we buy a tech and then try to fit a solution to what we have which is exactly backward.

    If you are a tech company then early adoption *may* be critical path but again only if it presents viable solutions.

    Like all things. . . "Depends"

    Don "I've seen teams is too impatient to make the Kool Aid, they tear open the pack and snort away. Sometimes that bites back" Bolton

  • Sean, agree your example is a valid one. Some people found it useful even with all the limitations, the rest of us look at it and wait/hope for the improvements without the tradeoffs. I don't see that as anti-early-adoption - has to work to be considered!

  • Eric, that's interesting, never thought about it in that way. Still thing if I agree, seems like one category missing - I just dont know what it is yet!

  • Joe, it's hard for me to visualize that change. My instinctive thought is that going in that direction is wrong, we should stay focused on the problem domain of data operations, but it's probably not that simple.

Viewing 15 posts - 1 through 15 (of 27 total)

You must be logged in to reply to this topic. Login to reply