January 29, 2008 at 7:27 pm
Comments posted to this topic are about the item Fixing SQL Server
January 30, 2008 at 12:29 am
I absolutely agree with you.
Additionaly I think a cycle of 2-3 years is really to short, every 5-6 years for a new SQL-Server version would be good.
For the moment the majority of our customers are still using SQL2K, new installations since last year are getting SQL2K5. And both versions are doing their jobs well.
Microsoft has to think about the work to do for software companies always to check if the programs are always running with new SQL versions, make new installation and update packages... Some companies are still working with VB6 and why aren't they upgrading to .NET? It costs too much! Ok the changes from VB6 to .NET are much bigger than between SQL2K5 and SQL2K8, but the work (manpower & working hours) has to be done.
Ok Microsoft has to make money, but for small- or midsized companies it must be doable...
Patrick SIMONS, MCP
January 30, 2008 at 2:09 am
I spent several years advising a large international manufacturing company on their software-purchasing strategy. It always amazed me how far the software companies, including Microsoft, misunderstood our core requirements. In presentation after presentation, they wittered on in detail about the features of their product in comparison with the opposition.
We didn't care. We just wanted a stable product that did what we wanted, was easy and cheap to maintain, didn't need lots of 'men in white coats' (geeks to you) and didn't keep changing.- that didn't cause trouble.
Even the IT department didn't fully understand this- they regularly became hypnotised by the marketing babble from Microsoft and others. I've kept the handouts for SQL Server 6.5, and it is hilarious to compare the promises to the reality.
We'd have rather preferred a five-year cycle, an option that was not available then as the products were so wobbly. Upgrading ones servers is risk, a distraction, and expense, and the gain is often too subtle to be seen by the accountants. We didn't like surprises. 'The pioneers end up with arrows in their backs'
Often, Software companies are talking to the wrong people within the businesses they serve.
What's wrong with a five-year development cycle? Nothing, and one day the more conservative business may even upgrade to SQL Server 2005 when enough service-packs have popped out.
Best wishes,
Phil Factor
January 30, 2008 at 2:28 am
I think the really telling sentence in the article is "So if they're going to shoot for a new release every 2-3 years to get people into Software Assurance and provide steady revenue, what should they do?".
Two things that really get my goat are stasis in the face of common sense ("why do you do this process this way? Because we've always done it that way." :crazy:) and change for change's sake ("Hey, it ain't broke, but let's fix it anyway" :crazy:), and this is the latter. I can understand why Microsoft want to keep producing new releases, but that doesn't mean it's the best thing for the customers. Aside from the fact they've stopped supporting it, I can see few reasons why many of my databases shouldn't be running on SQL6.5 let alone 2k.
All that is why I agree entirely about the suggestion of making features separate. Integration Services isn't a database function; it's a separate application however well integrated or useful. Software Assurance could be used to provide access to new related apps (such as Reporting Services, Integration Services etc) just as easily as forcing people to upgrade an already stable and working RDBMS, so why not do it that way?
Semper in excretia, suus solum profundum variat
January 30, 2008 at 3:17 am
Completely agree with you.
Microsoft do some things well. But they do almost anything but make it easy for their customers to schedule maintenance work. Regular and predictable maintenance slots are vital. If the product developers say they have too much time pressure to deal with service packs, then hire some people just to do this work.
Much of the complaints about upgrading to the latest software is tied to people not being used to applying maintenance. If you have a regular annual or 6-monthly slot to maintain SQL Server, then upgrading to the current release can fit naturally into one of these slots. If you have to fight for time to do a service pack whenever MS deem fit to release one, you have a far bigger fight to get time to upgrade to a new release.
BTW, one of the nice things IBM does when they release a new version of DB2 is make public the feature set of the V+1 release, and ideas for the V+2 release. What is stopping MS keeping their customers informed in this way?
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
January 30, 2008 at 4:16 am
Phil Factor (1/30/2008)
What's wrong with a five-year development cycle? Nothing
It's true that a nice long release cycle, like 5-6 years, gives customers plenty of predictability around server upgrades etc.
Unfortunately, long release cycles also guarantee that you'll end up with disjointed, unstable, inconsistent software, with very few significant features that justify the huge development investment.
Why? Consider how software is built, and by whom. Software developers don't stick around in the same job for more than 2-3 years on average, so a 6-year cycle guarantees you'll burn through two or three generations of developers - each generation bringing their own opinions and agendas, undoing the work of the last. Secondly, the IT industry moves too fast - 6 years is like the difference between the stone age and the iron age - techniques, trends and expectations become totally different, so the early work becomes a liability not an asset.
The perfect example of this is Windows Vista.
January 30, 2008 at 4:37 am
I am a former member of the SSRS (SQL Server Reporting Service) 2008 development team. I was a developer. I would like to respond to some of your points:
Stop the CTP Madness
Many customers have actually requested this. Also, this is just good software engineering IMO. When you have a typical release cycle of several years, your customers' requirements will have changed by the time you bring a product to market. The whole point of this is to involve customers in the development process and get feedback early and often.
Hire Testers
Very hard to find qualified people to do this job at any salary. Easily the most thankless job on the development team. They interviewed like crazy for testers when I worked there. They have the highest tester/developer ratio than anywhere I've ever worked. We test and test and test. We have days where everyone on the whole team would try out every feature of the product called bug bashes. I propose a new law of software testing "No matter how much you test, the first customer to run your product will find a bug in the first screen or action taken"
Make features separate
This sounds reasonable. Kind of like a la carte for features
Use R2s
I don't know, I think your splitting hairs. R2 == next version with less features? SQL Server faces a lot of competition, it has to add features and compete or it will die. Just don't upgrade if you're happy with the current version.
Lock the Doors
Sounds like a good idea but not really good business.
January 30, 2008 at 5:54 am
Ryan, thanks for posting on this thread. Unless there are opinions from several areas of involvement, any discussion is only so much guesswork.
I'm glad you see potential for crossover or agreement in as many areas as you do. However, the one area I'd still challenge is under the section of "Use R2s". You say "SQL Server faces a lot of competition, it has to add features and compete or it will die. Just don't upgrade if you're happy with the current version.", and I believe that to be a developer's answer through and through. Yes, SQL Server must compete or it'll die. No, it doesn't necessarily have to add features. If SQL Server 7 was still supported, I'd still have it installed on one of my boxes. Competition's not about numbers of features, it's about fitness for purpose. If people are in the position to choose between Oracle and SQL Server, they'll go for whichever fits their needs best, not the one with the biggest widget count.
As has been said elsewhere, and as you've agreed is reasonable, extra functionality (reporting services, analysis services, integration services etc.) could be provided be extra applications rather than trying to make an RDBMS into bloatware. Strip away all those extras, and how much has the core database server really changed?
Semper in excretia, suus solum profundum variat
January 30, 2008 at 6:57 am
I agree with the 5 year cycle. Really, the database world simply does not change that much to require new systems (and porting existing apps, and new hardware to support the new systems). I'd much rather have an upgrade or expansion path for new features and capacities if our requirements change greatly.
It's true that much of the selling is on fluff, features that most sites simply never use. What you need to sell product is NOT more 'features' but rock solid stability, upgrade path, and good support.
...
-- FORTRAN manual for Xerox Computers --
January 30, 2008 at 6:57 am
Ryan,
Thanks for the response and appreciate your insight and opinion. I'm sure that the testing part is hard and I don't have a solution to implement it. I can definitely relate to those challenges on a small scale.
The R2 thing could work since it's really a .5 release. They could charge a nominal fee, include it in Software Assurance, or even require some sort of software maintenance to keep supporting older versions. The maintenance contracts, from what I've seen, have large minimums and aren't well received. Part of that may be the idea that we get support for free from MS.
I haven't worked that all the way through, but I think there's something there.
On the CTP madness, it's like the kid joke problem with MS. You do something small, it's well received, and then you do it over and over and over. It's not funny anymore.
The same thing has happened with CTPs. It's like it worked well, so let's do everything this way and it's gotten confusing. What happens is that people install one or two CTPs, not 8. There are a few people that want all 8, but let them sign up. A CTP is a preview, not an advanced beta. Delineate things more clearly and we'll get involved.
This is the same group of people that say "customers don't ask for SP3". Horse droppings. they expect it, they're just don't think they need to ask.
The marketing folks have forgotten that for some products there's a nice settling in cycle. They can spend 1 year marketing 2008 before it releases and 2 years marketing 2008 after it releases. They don't need to dig into 2011 until 2010 to get it sold. I'd argue them working on 2008 since late 2006 is bad business. They don't need to sell the new features until this year.
January 30, 2008 at 8:00 am
Very well said! I agree but unfortunately we live in a world were stock holders need to make even more money. Technology (including DB systems) are actually driven by how much money they can make and not how can we help the lonely DBA.
Here's another idea to think about. Instead of a new release every 2 years, how about release a feature pack every 2 years. We keep the base and just expand on it. Think about it. In say 10 years we would have a rock solid system that no other company could even come close to it's abilities and stabilities.
We could pay for things we need and/or use. If I need mirroring, I'd pay extra for it. If I need reporting service then I'd pay for that too.
Let the product mature and become more valuable to everyone, including the stock holders.
Maybe someone at MS will read this and prove me wrong but I won't hold my breath.
Just my 2 cents worth.
Rudy
January 30, 2008 at 8:02 am
In developing SQL Server, we had the concept of an "improvement". This was a set of features revolving around a central theme. For example, one improvement was the Sharepoint integration for Reporting Services.
See this chart for the various improvements in a ctp:
https://connect.microsoft.com/SQLServer/content/content.aspx?ContentID=5470
IMO, the CTPs are mainly targeted towards people who are chomping on the bit waiting on those improvements. This helps the development team get early feedback. If you aren't interested in any of the improvements in a CTP, you can safely ignore it.
January 30, 2008 at 8:07 am
Rudy Panigas (1/30/2008)
Here's another idea to think about. Instead of a new release every 2 years, how about release a feature pack every 2 years. We keep the base and just expand on it.
That's exactly how the software is developed anyway. They don't start from scratch every time. Marketing it as a brand new product gets more people to open their wallets, but of course it's built on the old product.
January 30, 2008 at 8:07 am
I have to agree with the idea of a 5 to 6 year period between releases. I currently work in a mid-sized company developing specialized software for a group of around 300 users. Our focus has been to develop new software and replace old mainframe software to make the users jobs more efficient. We currently have no SQL 2005 installs and still have a SQL 7 install. The reason being we do not have the time or the manpower to move and retest all of the applications (written by consultants long before our development team existed) that currently use the old SQL 7 machine. Most companies whose primary business is not IT may find it difficult if not impossible to keep up with new releases to server software, and the required testing, when they are trying to create software that the users need to do their job. In our shop we are still using VS2003 and .Net framework v1.1 because the upgrade to the new versions had incompatibilities that would require us to make changes and retest all of the applications we had built in the last several year. The users don't care if we are using SQL2005 they just want the tools they need to do their job.
January 30, 2008 at 8:15 am
The users don't care if we are using SQL2005 they just want the tools they need to do their job.
Hi Judith,
that's really the point that Microsoft will not understand!
Patrick SIMONS, MCP
Viewing 15 posts - 1 through 15 (of 21 total)
You must be logged in to reply to this topic. Login to reply