September 22, 2014 at 5:55 am
Tavis Reddick (9/22/2014)
TomThomson (9/22/2014)
Tavis Reddick (9/22/2014)
Anyway, whenever I hear a DBA saying something like "I see no compelling reason to upgrade" my eyes turn red, smoke issues from my nostrils and I reach for that large, heavy latest version of the SQL Server Bible I've been reading for the last month, stuffed with bookmarks on new DML improvements and…And whenever I see a developer throwing a tantrum and screeching "I want I want I want" because he's seen expensive new toys in the shop window I feel sad that some developers never learn. Most of my background is R&D, but although I too like new toys I have also had a responsibility to help ensure the survival of the company which employed me, which sometimes has meant that new toys had be delayed.
My overall comments had a serious theme but an exaggerated style (intended to balance what I saw as a rather one-sided thread full of (legitimate) DBA concerns.
I have heard people who call themselves developers talking about "new toys". I would not use that term, and I think it is unnecessarily derogatory and provocative in certain situations.
SQL Server development has been driven by customer demands, the changing world outside databases (the world they are supposed to model: for example by geographical data types) and even the SQL standard itself. Serious developers will be aware of this process and even part of it.
T-SQL is, in many respects, a wonderful declarative language, but there is always scope for improvement and always new problems to solve. Code management is such a huge issue for some organizations that even what may seem relatively minor improvements can reduce complexity by orders of magnitude (I gave an example). The movement towards elegance in coding is not something just to be appreciated for its abstract beauty, but for real-world gains in productivity, performance and efficiency.
I grant completely that not all developers work this way, and these issues are really not relevant for a lot of organizations who do not change their own code, but respect is due to the deep thinking on solving classes of problems that has gone into the vast amount of improvements made in SQL Server over the years, even if many are only of significance to a minority.
Tavis, I am one of those developers who highlighted that SOME developers want "new toys" and expect to always get them because they do not (want to?) see the larger picture.
I also struggle with how you can write in that "exaggerated style" then accuse others of being "unnecessarily derogatory and provocative". Pot? Kettle? (For those from a different culture than mine there is a phrase "the pot calling the kettle black" which originates at a time when pots and kettles were all black and is used to describe someone who is accusing someone else of being/doing/saying something that they are/are doing/said themselves).
There are cases where updates can be justified solely on the benefits in software development productivity but that is often not the case. It is not that DBAs don't want to upgrade. It is just that they cannot justify it.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 22, 2014 at 6:03 am
Gary Varga (9/22/2014)
Tavis Reddick (9/22/2014)
TomThomson (9/22/2014)
Tavis Reddick (9/22/2014)
Anyway, whenever I hear a DBA saying something like "I see no compelling reason to upgrade" my eyes turn red, smoke issues from my nostrils and I reach for that large, heavy latest version of the SQL Server Bible I've been reading for the last month, stuffed with bookmarks on new DML improvements and…And whenever I see a developer throwing a tantrum and screeching "I want I want I want" because he's seen expensive new toys in the shop window I feel sad that some developers never learn. Most of my background is R&D, but although I too like new toys I have also had a responsibility to help ensure the survival of the company which employed me, which sometimes has meant that new toys had be delayed.
My overall comments had a serious theme but an exaggerated style (intended to balance what I saw as a rather one-sided thread full of (legitimate) DBA concerns.
I have heard people who call themselves developers talking about "new toys". I would not use that term, and I think it is unnecessarily derogatory and provocative in certain situations.
SQL Server development has been driven by customer demands, the changing world outside databases (the world they are supposed to model: for example by geographical data types) and even the SQL standard itself. Serious developers will be aware of this process and even part of it.
T-SQL is, in many respects, a wonderful declarative language, but there is always scope for improvement and always new problems to solve. Code management is such a huge issue for some organizations that even what may seem relatively minor improvements can reduce complexity by orders of magnitude (I gave an example). The movement towards elegance in coding is not something just to be appreciated for its abstract beauty, but for real-world gains in productivity, performance and efficiency.
I grant completely that not all developers work this way, and these issues are really not relevant for a lot of organizations who do not change their own code, but respect is due to the deep thinking on solving classes of problems that has gone into the vast amount of improvements made in SQL Server over the years, even if many are only of significance to a minority.
Tavis, I am one of those developers who highlighted that SOME developers want "new toys" and expect to always get them because they do not (want to?) see the larger picture.
I also struggle with how you can write in that "exaggerated style" then accuse others of being "unnecessarily derogatory and provocative". Pot? Kettle? (For those from a different culture than mine there is a phrase "the pot calling the kettle black" which originates at a time when pots and kettles were all black and is used to describe someone who is accusing someone else of being/doing/saying something that they are/are doing/said themselves).
There are cases where updates can be justified solely on the benefits in software development productivity but that is often not the case. It is not that DBAs don't want to upgrade. It is just that they cannot justify it.
There is a fine balance I know. You cannot stay in the past as you will fall behind... and there ARE some features that apps and companies can take advantage of. 64 bit was a huge leap forward. However, for the bulk of dept based and small companies there is NO benefit to upgrading. We have 45 SQL Server installs here and if I went to my boss and said I want to upgrade all of them and gave him the licensing bill he would just laugh... He would laugh even harder when I have no justification at all for 90% of them. Again there is a fine balance to upgrades of everything. You do have to stay within support.
I am sure the folks that are in charge of Microsoft Office, Access, etc at large and small companies with the question of upgrade or not to upgrade fight with this. The expense is huge and what new features are in the new version and how many in the company will take advantage of them. For the bulk of folks Office 2000 would work just fine.
September 22, 2014 at 7:04 am
I am a database consultant and work with a variety of clients. The number one reason for not upgrading is, first, last and always, the cost! Not only are we talking about the monetary cost (not to mention the confusion) of getting the correct licensing but there is also the ancillary costs associated with new Hardware, new Operating System. Add to that the cost in employee time involved in actually doing and testing the upgrade and you start to get some horrific numbers.
When you also consider that most companies of any size will have multiple databases, and will also have SSIS packages (usually means a new version of Visual Studio and another set of hardware and software requirements to consider), SSRS reports and maybe SSAS cubes - all of which have to be upgraded, tested and verified and you are suddenly looking at thousands of man-hours of effort (and associated cost).
Believe me, there has to be a really compelling BUSINESS advantage to warrant such an effort and the associated cost.
In smaller organizations (less than a dozen dedicated IT professionals) a SQL Server upgrade will almost certainly require external Consultants/Contractors because the in-house staff just won't have the spare capacity to undertake the additional workload. This adds yet more "hidden" costs.
Right now I am working with a global client to upgrade from SQL 2005 to SQL 2012 (yes, 2012 - not 2014!). The business requirement driving this project is to implement Master Data Services across the five divisions (Americas, Europe, Africa, Middle East, Asia Pacific). The true cost of the "SQL Upgrade" is going to run into hundreds of thousands of dollars, has already been almost a year in planning and will require a massive effort from IT.
This is not something the company is going to do every 24 months just so that MicroSoft can sell a few more server licenses to them.
It has long been my opinion that MS needs to get real about what constitutes a 'REASON' to upgrade. It would be better if they would focus on fixing the bugs and omissions (and charging for the Service Packs if necessary) in current versions, rather than creating "new" versions of their product with "features" that no-one really wants or needs every 2 years. However, that has been the Office model for many years (who really uses more than about 10% of the functionality introduced since Office 2000 in Word, Excel or PowerPoint?) and unfortunately it is now bleeding over into SQL Server!
----
Regards
Andy Kramek
September 22, 2014 at 7:21 am
Tavis Reddick (9/22/2014)
My overall comments had a serious theme but an exaggerated style (intended to balance what I saw as a rather one-sided thread full of (legitimate) DBA concerns.
And my comment was to point out that these are not DBA concerns, they are business concerns and are relevant to everyone in the company, especially to senior management and to R&D management (who should be developers) in particular.
.....and these issues are really not relevant for a lot of organizations who do not change their own code, but respect is due to the deep thinking on solving classes of problems that has gone into the vast amount of improvements made in SQL Server over the years, even if many are only of significance to a minority.
I've never worked in an association that didn't change its own code, and I've always advocated getting the latest tools, the newest possible technology, that was justifiable in business terms. But it's usually been clear that there are clear limits on what is justifiable in business terms and that there are tools or technology that have to take higher priority for upgrade that SQL Server, especially at the stage of growth where cost reduction is essential.
Tom
September 22, 2014 at 7:36 am
crussell-931424 (9/22/2014)
We're on 2008 R2. We'd have to pay 30 grand to upgrade. Our 2008 works just fine. So we would be upgrading for what?
Surprised it isn't more! 😀 My last client was quoted over $250,000 (granted they were a multi-national) to upgrate from 2005 to 2012. In the end they went to 2008R2 and all works just fine.
qh
September 22, 2014 at 7:56 am
TomThomson (9/22/2014)
I've never worked in an association that didn't change its own code, and I've always advocated getting the latest tools, the newest possible technology, that was justifiable in business terms. But it's usually been clear that there are clear limits on what is justifiable in business terms and that there are tools or technology that have to take higher priority for upgrade that SQL Server, especially at the stage of growth where cost reduction is essential.
Fine, I agree with pretty much the essence of what you are saying. However, justifications are still somewhat subjective and depend on a future projection of business need for which there may not be a consensus. You may be able to justify accruing a large amount of technical debt, for example, although the burden of that debt may be unevenly distributed in your organization, which may induce stresses if that is not recognized at decision time.
One example is the problem of replacing technical staff with experience of older systems, if younger staff are only trained in the newer versions (and we have had recruitment problems in this area ourselves).
All I am really asking for is that appropriate weight be given to developer views that are (as they should be) backed up by research and checkable references or tests.
September 22, 2014 at 9:42 am
Tavis Reddick (9/22/2014)
Will nobody think of the developers? 🙂Seriously, if humankind had adopted "If it ain't broke, don't fix it" we'd still be living in caves and drinking out of puddles. Requirements change! Expectations rise! New ways of thinking emerge!
[/url]
In each release of SQL Server, Microsoft has the opportunity to introduce innovations, typically ones that a mass of developers have been crying out for. How I fumed when our DBAs refused to install 2005, with its greatly-enhanced XML support, leaving my colleagues to write a complicated sequence of 18 related SQL objects whose output I still had to convert to XML. Every change to improve or debug this code set inflicted horrible pain (on me, not the DBAs). After upgrading to 2005, these objects were replaced with a single stored procedure and a user-defined function that outputted the XML directly. I could even implement some changes given to me over the phone as I listened and typed into the test/development environment and tested the results: "Yep, that worked" I could say before putting the phone down. Goddamit!
And yes, every new server had the latest SQL Server on it, but the old ones were not upgraded. So I had learnt all the new features (reading SQL Server 2005/2008 Bibles amongst other sources) but then had to mentally regress to apply solutions in a later version of T-SQL to an earlier version, or versions.
Even between 2008 and 2008 R2 there were huge improvement in Reporting Services.
Anyway, whenever I hear a DBA saying something like "I see no compelling reason to upgrade" my eyes turn red, smoke issues from my nostrils and I reach for that large, heavy latest version of the SQL Server Bible I've been reading for the last month, stuffed with bookmarks on new DML improvements and…
Certainly we think of developers, but you must have time to refactor code or use the new features. I would argue that for many companies, and many applications, the new features are not going to outweigh the cost of the licensing changes. Or at least, it's hard to prove that developers writing code with new features generates enough new revenue to make a positive ROI.
That's not always the case, but in many places I've worked, that certainly has been true.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
September 22, 2014 at 10:41 am
As SQL Server becomes more and more out there with more and more installations running small and mid sized apps upgrades are going to be harder to justify. The ROI just isn't there for these types... the leaps and bounds of speed of servers and new features not as big as they once were is going to make justifying it harder and harder. I know here it is getting more and more difficult. The new projects are the cool sexy ones... once it is in production and running for a couple of years it becomes back burner and then the cost justification gets harder.... people say... it works fine... Senior Mgt wants the NEW stuff as they justify cost savings for this or that Department... The current ones are just there now running the business. There is no cost savings to the company to justify an upgrade. Telling Sr. Mgt that a process will run faster when you don't miss a processing window isn't going to get a big $$ project approved.
September 23, 2014 at 3:30 am
I too am a developer, but also an accidental DBA (as is often the case in small software companies). It is understandable that those tasked in large organisations with keeping applications up and performing have other priorities then those writing new or extending existing applications. Especially if they miss lots of information about the importance of each and every application.
For a developer it can be very inefficient to deal with feature incomplete systems (SQL Server 2000 and 2005 for example). Even later versions introduced some features that can be real time and cost savers, some of which a DBA might not appreciate as it is outside his view and direct responsibility. Both DBA and developer service the same company/customer and get paid form the same revenue stream, so neither can claim exclusive rights on what is good for the company.
Now from a DBA point of view, it is good to prevent large risks due to changes with no clear benefits. Be that guardian, but please do inquire why an upgrade is required and offer alternatives if you think the reasons do not justify an upgrade. Be prepared to support different servers with different versions of MSSQL running on them. If an application needs an upgrade and an application is testable then by all means let it be modernized! It will pay off in the future!
Run newer version on a smaller, cheaper Standard instance first. This lets you test the waters with less critical applications and allows apps modernization per app and at different speeds. It certainly is not a DBA's responsibility to be the final judge of the importance of every application and have a final say in all things affecting the company. Being cautious is good and all, but do not overdo it as that will simply hurt the very company you serve and generate polarization.
September 23, 2014 at 6:52 am
peter-757102 (9/23/2014)
...For a developer it can be very inefficient to deal with feature incomplete systems (SQL Server 2000 and 2005 for example). Even later versions introduced some features that can be real time and cost savers, some of which a DBA might not appreciate as it is outside his view and direct responsibility. Both DBA and developer service the same company/customer and get paid form the same revenue stream, so neither can claim exclusive rights on what is good for the company...
I suppose it depends if the company has true database developers or if they have the application developers doing the database development. As a DBA, I've seen that companies with dedicated database developers are more interested in new database features, while application developers care more about the latest .Net enhancements or web technology enhancements than database enhancements. I'm not saying application developers who like database enhancements don't exist, just that typically it's not a driving force for them, and I've had to teach them new techniques and features available with database upgrades.
Viewing 10 posts - 61 through 69 (of 69 total)
You must be logged in to reply to this topic. Login to reply