RE: Launching Products – SQLServerCentral

SSC Guru

Points: 1003863

March 25, 2017 at 9:58 pm

#1934968

Steve Jones - SSC Editor - Wednesday, March 22, 2017 8:25 AM
Sean Redmond - Wednesday, March 22, 2017 2:42 AM
I've mentioned it many times before but I'll say it again.
Products now are released too often and often with little in them to justify the hassle and cost of getting the upgrade. Most releases have something nice in them but not enough to make a convincing argument. The release-time is too short.
We are getting new versions of SQL Server every 2 years (2005, 2008, 2008R2, 2012, 2014, 2016...). MS Office & Adobe products are no better.
I'd much rather that they made it every 4-5 years and made each release so compelling that upgrading seemed the natural thing to do, as it was with SQL Server 2005 or Office 2007.
Why? You don't have to upgrade every two years. You could skip every other version, get your four year upgrade, and get more features.
Releasing less often, means lots of work sits in development, no idea how useful it is, the flaws others might see, how much could be done to improve it and more. I like the idea of them releasing every 2 years. Get some features, make the upgrade decision. I'd probably go every 3 versions myself (or longer) for any particular instance.

I've found that if you slow down on the number of releases and spend some time on full integration and testing, you end up spending a whole lot less time with urgent bug fixes that are necessary because the bugs are affecting customers. There's actually a highly beneficial cascading effect because the more you release bug free code, the more time you have to write bug free code. The inverse is true, as well. Release to meet some artificial schedule because someone wants it real bad and that's how the code turns out... real bad. No one accounts for the time such bad code is going to take for rework and so they don't change the release schedule and you're suddenly in a crunch for time, which causes more bugs and you end up in a death spiral of releasing more bugs that cause more rework that causes less time to write code which causes more bugs and... etc, ad infinitum until someone actually stands up a puts a halt to it all. Sometimes it's a manager that's tired of being bruised and sometimes it's a pissed off Developer that finally found the religion of quality.

We tried the ol' "continuous deployment" thing and the number of bugs went way up. We normally have zero bugs on a "normal" release. We don't do "continuous deployment" any more. Instead, we take our time and do it right the first time.

Can you have continuous deployment AND quality? I'm sure you can and someday, someone will actually do it once or twice once they realize that "continuous" isn't a synonym for "urgent". 😉

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)