March 25, 2017 at 9:58 pm
Steve Jones - SSC Editor - Wednesday, March 22, 2017 8:25 AMSean Redmond - Wednesday, March 22, 2017 2:42 AMI'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
March 25, 2017 at 10:36 pm
I worked in the video game industry for 7 years before I landed where I'm at today.
One thing I miss is our product launch parties. Some of them have included huge events with beer, live bands, fans flown from all over the world, and lots of press coverage. Others have included renting of Yachts, booze busses, live dancing and so much more.
When it came to team launches, these are always the best too. Private parties, good food and mostly pub crawls around Europe.
March 26, 2017 at 9:53 am
xsevensinzx - Saturday, March 25, 2017 10:36 PMI worked in the video game industry for 7 years before I landed where I'm at today.One thing I miss is our product launch parties. Some of them have included huge events with beer, live bands, fans flown from all over the world, and lots of press coverage. Others have included renting of Yachts, booze busses, live dancing and so much more.
When it came to team launches, these are always the best too. Private parties, good food and mostly pub crawls around Europe.
Oooooo... that brings back some serious oldy-but-goodie memories. I worked part time for Gremlin Industries way back in the 70's working on power supplies for the big console video games for arcades. I ended up working myself out of a job because I optimized the burn-in and final-test methodology. I created a test box that increased my personal throughput by a factor of 10 and rebuilt the burn-in rack to have a timer and separate set of controls on each shelf so they could do partial runs based on when they had enough power supplies built to fill a shelf so they didn't have to wait for enough to power up the whole rack. Think of it as a form of hardware "continuous deployment". My going-away party was incredible.
They also gave me the grand tour of the facility. It took a whole day. Testing of the code was absolutely amazing and they ALWAYS ended up with 100% bug free code. They had to... the internet certainly wasn't what it is today back then. The concept of pushing fixes out to thousands and thousands of consoles back then simply didn't exist.
Heh.... I guess we can ultimately blame Al Gore for today's poor code quality, eh? 😉 😉 😉
--Jeff Moden
March 27, 2017 at 7:16 am
Jeff Moden - Saturday, March 25, 2017 9:58 PMWe 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". 😉
That's the crux. When you argue against CI/CD/DevOps, I'd like to see the argument make sense. There's nothing wrong with those ideas. They can be implemented poorly or well. Just making things more urgent or releasing more often isn't actually going to change anything. However, I'd say that's not DevOps, or even CI/CD.
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
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply