November 20, 2015 at 2:51 pm
I learned NOT to be an early adopter of anything long before I started working with SQL Server. After seeing things like 2000 SP3, 2005 RTM, 2008, 2012 RTM, 2014 SP1, etc, etc, I'm really, really happy to sit on my fists and lean back on my thumbs and let other people be early adopters. I've got enough to do without fighting problems in manufactured code.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 21, 2015 at 7:58 am
I haven't worked with SQL Server as long as many of you guys. However, working in the software industry for a long time now, early adoption of anything is rarely pursued in my experience. I am normally against the early adoption simply because the product or service is unproven regardless of the marketing drivel.
You just have no idea. You're the first one off the boat and there could be a army waiting for you to land and destroy you and your project without batting an eye. So, why risk it?
The unfortunate reality is this exists for all teams and industries. When I worked in marketing, we never presented at a convention or trade show in it's first 3 years. This is because again, it's unproven. Why risk the money until it grows?
I do hate not being to use the latest hot products and services though. I do want to use SQL Server 2016 as soon as possible. But, even if I was silly and bought into the license early on, even the business has policies within IT that simply do not support early adoption either. The security risk is high and the resources to support it from a service level is non-existent until the product proves itself in the market.
November 22, 2015 at 7:16 am
I'm finding that as an early adopter that there are an awful lot of people who claim they are doing something but when they are scrutinised its all smoke and mirrors.
Being a team charged with early adoption of technology is incredibly stressful. You will be hitting the problems for the first time and Google knows nothing! Chances are the vendors will be facing your particular application of their technology for the first time as well.
What you really really really need is a culture that understands and accepts that your are implementing something that is unknown, high risk and difficult. Project estimates are SWAG estimates at best and not something on which to schedule subsequent initiatives with your project as the lynch pin on which it all hinges.
Apart from the stress and distractions nothing binds a team together like adversity and a shared challenge. It is a chance to learn one hell of a lot in a short space of time. It is also the chance to establish the practises that you wish to abide by. There is no-one who says "yes, we know that to do it properly you should do 'x' but can we have a tactical solution?" No-one actually knows if a tactical solution exists, much less whether one is possible.
November 22, 2015 at 8:03 am
David.Poole (11/22/2015)
Apart from the stress and distractions nothing binds a team together like adversity and a shared challenge. It is a chance to learn one hell of a lot in a short space of time. It is also the chance to establish the practises that you wish to abide by. There is no-one who says "yes, we know that to do it properly you should do 'x' but can we have a tactical solution?" No-one actually knows if a tactical solution exists, much less whether one is possible.
Problem is with companies like mine, that's good for the team and not good for the business. Needs to be both to succeed in their eyes.
November 22, 2015 at 8:42 am
Problem is with companies like mine, that's good for the team and not good for the business. Needs to be both to succeed in their eyes.
Yes but if you start off with compromised foundation stones you will never recover. There is a huge hidden cost in tactical solutions. In my experience tactical solutions aren't tactical and they sure as hell aren't solutions!
It is very easy for an IT person to cost £1/minute. A tactical solution only needs to add a little friction to processes in order to outweigh any benefit in taking the short cut.
Again, from experience the additional BAU work generated by a tactical solution tends to be absorbed and only becomes visible outside of the IT department when important and truly strategic stuff needs to be done and the resource is being burnt on someone's quick bodge.
I'm not saying we shouldn't release value early. I'm saying that we need to be extremely careful about the priority calls that are made.
November 22, 2015 at 9:57 am
I have to say with my experience, I am with David on this one.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 23, 2015 at 6:56 am
Last time I was an early adopter of SS was way back in the SS 7 days. Those changes made sense right out of the box. (And SS was cheap in those times.)
Now I wait to spend money. The only "early" adoption I do is usually with OSS, and it's not early, just most unknown to most of the corporate world.
November 23, 2015 at 1:36 pm
We can't risk the potential problems of early adoption.
November 23, 2015 at 1:55 pm
What does it take to identify and mitigate those risks? Is it having CU1 or SP1? 6 months on the market? Even if you're upgrading from 2008 to 2012 there are risks and 2012 has been out for a while. I get not upgrading on day one, but when does it shift from "early adopting" to "this makes sense" to "the rest of the world is passing us by"?
November 23, 2015 at 3:00 pm
If you are talking about early adoption of the latest version of SQL Server then having a comprehensive set of functional and non-functional tests will mitigate those risks.
If you are talking about implementing a new feature in a new version of SQL Server then again a robust test strategy is the mitigation. The platform is fundamentally mature.
If you are talking about fundamentally new technology then here be dragons. It's not just about being first to use the technology its probably going to be the first to use a technology in a particular way.
November 25, 2015 at 9:55 am
If you are talking about fundamentally new technology then here be dragons. It's not just about being first to use the technology its probably going to be the first to use a technology in a particular way.
Depends on how "new"?
SQL Server folks and clients are can be conservative. Mention SSD, R, git, Python, another RDMS or any non-mainsteam commercial vendor/OSS to some and you may be shunned.
I got chewed out by a well know SQL Server pundit when I mentioned I used Linux and Python to pre-scrub and aggregate a couple of terabytes of open data before importing it into SQL Server.
Apparently I was supposed to suffer and use SSIS for all data tasks, even those that it isn't always the proper tool. But it was my project and I quoted Buck Woody back at him, which made the situation even more terse. Maybe pointing out that his Android phone was a running a version of Linux or mentioning "Data doesn't care about language or OS, data just is...."
November 25, 2015 at 5:37 pm
Errrrmmmm, but Linux has its basis in Unix has a number of text processing utilities that can pipe their output into each other. Sed, awk, tr, wc, split, join. It also has the ability to pipe stdin, stdout and stderr into files.
A bit of bash scripting with these utilities can achieve much that the majority of ETL tools are used for.
It's probably a heretical thought but the ability to pipe together transforms in a script would probably be something that could be more easily unit tested than a GUI based ETL tool.
November 26, 2015 at 4:37 am
David.Poole (11/25/2015)
Errrrmmmm, but Linux has its basis in Unix has a number of text processing utilities that can pipe their output into each other. Sed, awk, tr, wc, split, join. It also has the ability to pipe stdin, stdout and stderr into files.A bit of bash scripting with these utilities can achieve much that the majority of ETL tools are used for.
It's probably a heretical thought but the ability to pipe together transforms in a script would probably be something that could be more easily unit tested than a GUI based ETL tool.
Yep. MS know this. Hence PowerShell. I suspect that at least of MS developers wouldn't have developed SSIS the way it is.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 13 posts - 16 through 27 (of 27 total)
You must be logged in to reply to this topic. Login to reply