Kamikaze
I can see how bugs are unavoidable

It is incredibly hard to write bug-free software, certainly. It's not unavoidable - just impractical. The benefit of fixing a bug is often less than the benefit of adding a feature, and that is because users are not voting with their feet and demanding stability and correctness. It's our fault, as users.
 
Here's something I saw today - someone has tried roughly 473 million different inputs, some legitimate and some not, to try and get the SQLite database software to crash, and not once did it do so. Yes, it's 'only' 200,000 lines of code. But that's still an impressive achievement - and all because they've put stability and correctness first. (Which in turn is because their users demand it.)
 
(EDIT: had 'cost' where I meant 'benefit'. Duh.)

ChristopherM

Andrew Rossa [Cakewalk]

ChristopherM
The suits.

Going to be tough to find a person wearing a suit at Cakewalk :)

Andrew, dear boy, suitism is an attitude, a stance, a philosophy - not a garment or raiment. 

This information might have been helpful sooner. I spent all day scouring the office for these folks:
 
https://en.wikipedia.org/wiki/Mad_Men#/media/File:Mad_Men_season_5_cast_photo.jpg
 
 

Kylotan

Kamikaze
I can see how bugs are unavoidable

It is incredibly hard to write bug-free software, certainly. It's not unavoidable - just impractical. The cost of fixing a bug is often less than the benefit of adding a feature, and that is because users are not voting with their feet and demanding stability and correctness. It's our fault, as users.
 
Here's something I saw today - someone has tried roughly 473 million different inputs, some legitimate and some not, to try and get the SQLite database software to crash, and not once did it do so. Yes, it's 'only' 200,000 lines of code. But that's still an impressive achievement - and all because they've put stability and correctness first. (Which in turn is because their users demand it.)

bump

Kylotan
that is because users are not voting with their feet and demanding stability and correctness. It's our fault, as users.

Last time I saw there was no voting going on, just loads of threads here going nowhere. Perhaps I should saw off my foot and send it in the mail.

mettelus
The critical nature of bugs is definitely a massive factor, and this article seems to want to lump them into one big bucket, which is definitely not true.
 

Ummmmm.
 
"The value of a any given bug can be rated by the number of users affected times the criticality of the issue. Lots of users are losing all their data due to this bug? Okay, then, Very Damn Important! Fix it NOW! Lots of users are a little annoyed or confused by this? Probably should fix it some time soon. A few users have to spend another 30 seconds on a work around? Unlikely to get fixed any time soon!"
 
I see no "lumping" in that statement.

Noel Borthwick [Cakewalk]
This link also has some good reading if you want to understand the philosophy behind the "release early, release often" paradigm. A lot of software in the open source and closed source communities follows this paradigm and its part of agile methodologies as well.

Noel,
Thanks for the link, however, I thought our discussion was at a much deeper level than the Wikipedia definition of a simple philosophy like RERO, i.e. I thought we were discussing the finer points of  “software development release planning”.   I would call your attention to the section on The Upside of Quarterly Releases in The CIO Handbook by N. Colisto.  Also, you may want to familiarise yourself with the work of Prof Guenther Ruhe at the University of Calgary who has published a number of papers in this area.    
 
Regarding RERO; keep in mind that in many instances a Quarterly release cycle may also meet the RERO philosophy, as does an hourly, daily, or weekly; it is situation dependant.  I wonder if the  “new customer” marketing aspect has been weighted too highly in the present Sonar analysis and the existing customer satisfaction too low.
 
Thanks for listening and good luck to Sonar in the future.

Whoever came up with that article has never played an Ubisoft game. 

"In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena—or, at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door."
 
In the grand scheme of things, any bug in Sonar has to be in the "shallow" category.  Still, it would be nice if there were certain updates where just about everything was stable.  A point where one could stop chasing one's tail and "live with it" for an indefinite amount of time.  I've given myself 12 months to determine where that point is and I'm hoping I'll find one.

jpetersen
Not sure how many clients I'd still have if I took that as a professional leitmotif.

Exactly. I code for a living -- complex financial models -- with results often used in public filings and / or as a basis for large investment decisions. As soon as I submit my work, recipients will pore over it , actively looking for errors, which, given the stakes, are not an option -- they could get me sued / fined. So I'm a lot less relaxed about stumping up money for something and accepting major bugs as a fact of life.      

Paul P
"In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena—or, at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door."
 
In the grand scheme of things, any bug in Sonar has to be in the "shallow" category.  Still, it would be nice if there were certain updates where just about everything was stable.  A point where one could stop chasing one's tail and "live with it" for an indefinite amount of time.  I've given myself 12 months to determine where that point is and I'm hoping I'll find one.

100% agree Paul. I may be falling victim to the availability heuristic due to spending lots of time in the studio,  but lately it is the compounding of errant behaviours that is really starting to niggle me. I understand the occasional 'botch getting out the door',  but  I don't quite understanding sending out another one to keep it company wrapped in a shiny new feature once you know it's there.  Just one release where I can get on with the job and I will be a happy camper:) More than happy to continue my membership, but we just need a stable release to drop back to where all of the essentials work. It was x3e,  but since patch points that is no longer an option.