sharke
Personally I believe Sonar should be rewritten from the ground up!

 
I fixed that for you 

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.

sharke
Personally I believe Sonar should be rewritten from the ground up in LISP and Ada :)

Yeah! But the LISP would be removed again by any decent de-esser.

I can see how bugs are unavoidable, but when bugs are fairly constant are running across different versions without being addressed. That to me is wrong. Part of the reason for new versions should be to be able to address those bugs, if the bug has a fundamental relationship to the previous version. If It doesn't have this relationship, then it should be fixed with a reasonable time frame.
 
Relating this to Sonar, I think it's reasonable for all inherited reliably reproducible bugs from X3 and before be dealt within the first couple of years, now we don't have a new version structure but a regular release structure.  

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
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.

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.

"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.

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. 

lingyai

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.      

But presumably your company has the money to pay for that degree of quality control, as well as personnel with the required expertise not to make mistakes. 
 
What I find more shocking is that a company like Apple with such huge resources continues to release buggy iPhone updates. The latest example of ransomware using a command and control center in the Tor anonymizer network to encrypt data and then demand a ransom from iPhone users is perhaps something Apple couldn't have prevented, but apparently they didn't anticipate it, either.
 
Then again, I presume the standards for disposable smartphone software are quite different from the standards for software on a 747...or a financial institution that lives or dies based on the accuracy of the software and the results it generates.
 
A factor that's often overlooked is how much are people really willing to pay for bug-free software? I'm not just talking about SONAR by any means. When you have a tiny, overcrowded market competing with free downloads from torrents, and users who by and large aren't CEOs of multibillion corporations and don't have a lot of disposable income, something's gotta give. I'm sure SONAR could be very close to bug-free if Platinum cost $15,000.
 
But there wouldn't be enough users willing to pay that, so the point is moot. People already complain that paying $99 - $150 for a years' worth of upgrades is too much. Unless you have a lot of users, that's not enough to keep the lights on and pay what good software engineers cost these days. Those same software engineers will happily take a whole lot more money from Citigroup or whatever.

Anderton
Come to think of it...I don't know any software engineers at any company in this industry who are in it for the money, because the money just isn't there. They do it because they love working with music software. I think that's one reason I get impatient with people who complain a lot...we're all lucky we have any music software at all.

You can look at that the other way around :  the only reason we're using music software is because someone wrote it and put it up for sale.  If they hadn't, we'd all be playing our guitars.

Anderton
I spent enough years playing guitars into analog tape. I'm glad that software exists 

"I really miss my 4 track cassette recorder" said nobody ever. 

Well said Tobias -  great memories. 

Kylotan
 
I said nothing about whining. I'm saying that people who benefit from consumers accepting a lower standard of quality from software than from their other products should be treated with scepticism when they tell us to do exactly that.
 
The 'useful software' you refer to includes a web framework that had security flaws in it bad enough that many servers got taken over and used as botnets by hackers. No wonder, perhaps, that he wants to make excuses for why it is that way.
 
EDIT: Oh, I see someone already spotted and posted about this. Good work.

Fair enough, and point taken.