Cynical Snott
 
Wake up to yourself Anderton, get a reality check and actually smell what you are shoveling in the many ridiculous posts you make.

Sigh. Reasonable people are just trying to have an intelligent discussion about a topic that means something to them. Nobody cares about your opinion of Craig, or anybody else.
 

Cynical Snott
First off, If Cakewalk (Software Developers) aren't in it for the money, then they should just put their products up for free, why don't they?

 
I see our persistent little friend from Australia is back again. Per usual, I will answer your questions in a civil manner despite the absurdity of your premises.
 
Logical fallacy. Not being into something for the money does not require giving something away for free.
 

Talking of DAW developers, the only one I know of who isn't in it for the money is Cockos [snip]  And please don't go on about how they have XXX millions from the sale of Winamp, that has nothing to do with the ridiculous comment you made

You don't have to be into something for the money when you have hundreds of millions of dollars; you can afford to take chances other's can't. Besides, I mentioned ALL software companies, which includes Cockos. You cannot deny this is a low-paying industry. Take Ableton, makers of a very successful program with a loyal user base, founded by two people who wanted the software for their own live performances. Take their gross income, divide it by the number of employees (both are a matter of public record) and then try to tell me they're in it for the money. 
 
You fail to realize that different programs appeal to different people for different reasons. If Reaper was the best DAW in the world, then you wouldn't come in here and promote Studio One, and Avid would have gone out of business years ago. There is no one best DAW. Different DAWs appeal to different people. Having stated the programs you like, I am mystified why you keep returning to a forum whose purpose is to help users get the most out of the program they prefer to use. I have not seen you contribute anything toward that goal, and your use of multiple alts is a consistent violation of the terms of service.

Reply to Bristol Jonesey
I'm in the corner with the (other) people who think that MAYBE if new features were released LESS frequently then NEW bugs will be introduced LESS frequently and consequently the LONGER TIME in between releases would allow for MORE PATCHING of the previous release. One of those patched releases with NO NEW content/features might well be considered a 'golden release'.
Even though it has been said that the mere effort of patching bugs in itself introduces new bugs I am quite sure that by solely fixing bugs less (new) bugs are introduced as opposed to fixing old bugs PLUS adding new features (and bugs)

Bristol_Jonesey

M@

Mystic38
..... as at no time is there a known gold release to fall back to, ....

This is my main issue with the current system!!
Perfectly described.

But surely it's not just an issue with the current system per se, it's an issue with all previous systems and in the case of the annual update model, would quite possibly render the entire package useless (think the initial release of X1) and with no rollback possible.

X1 was a major rewrite and as such a special case.
When X3 came out, yes, it had issues. But for the rest of the year these were addressed, culminating in X3e.
 
I am back on X3e because of Platinum's current audio engine lock-up problem.
 
Rolling back and testing each Platinum release to find where the audio engine bug started took too long.

Craig,
I am glad that the recent post from Cynical Snott didn't dampen your enthusiasm.  Since you chose to "out" him/her as an Aussie I'd like to take this opportunity to apologise for my fellow countryman.  You are, of course, appreciated and respected down here as I suspect is the case around the world. 
 
That said, it may be useful to see what posts might be frustrating him/her and whether they are valid (from a purely logical point of view of course).  I will illustrate some of the types of posts that can frustrate with a fictitious thread that will not be personal (unless others choose to take it that way).  
 
Joe has purchased and Acme automobile and has encountered a problem.
 
Joe:  I have a 2013 Acme and am unable to shift into 2nd gear.
 
Poster 1:  What color is it, how many miles does it have and where did you buy it?  We can't help you unless we have all the information.
 
Poster 2:  Have you ever had 2nd gear?  Maybe you don't know how to drive. 
 
Joe: Yes I know how to drive and yes, I did have 2nd gear up until a week ago.
 
Poster 2:  I have been driving since cars didn't have windshield wipers. You don't know how good you have it.  Quit complaining.
 
Poster 3:  I too have been driving a long time.  In my day they didn't even have a speedometer.  These kids don't know how good they have it do they Poster 2.
 
Poster 4:  Are you criticising Acme cars.  If you are then you are criticising me since I own one!  Acme is the BEST!
 
Poster 5:  I know the people at Acme, they are all car enthusiasts and do not work for the money.  You shouldn't really be so negative.
 
Poster 6:  I have no 2nd gear on my Acme but have found a workaround.  I just shift from 1st to 3rd.
 
...
 
 
 

Joe completely blew off Poster 1. How can second gear be fixed without knowing the car's color???

Bugs.. Not taking away the fact that a software design, specification, communication, culture, it's test mechanism, personal vestment by the programmer towards their work, management commitment, and the quality of development play a huge role in reducing errors in software businesses They do.. But there are extrinsic errors introduced in software creation including the software compilers, hardware, operating systems, test systems, third party development tools, the list can get pretty deep and the risk of introucing errors goes up. We can add in customer product use and interpretation. These seem to me, to be inseparably bound. It

What makes sense to me for reducing defects is rapid release development, test and deployment, coupled with a relentless drive to eliminate waste by listening to each customer, employee, key vendors and other partners. Then, as a customer in this type of business model, freely share issues, and continue to do so with personal integrity, zeal, and care for those we interact with. A bit Pollyanna I know. Worth trying too.

I

LLyons
But there are extrinsic errors introduced in software creation including the software compilers, hardware, operating systems, test systems, third party development tools, the list can get pretty deep and the risk of introucing errors goes up. We can add in customer product use and interpretation. These seem to me, to be inseparably bound. 

But that's just the thing - the more often you compile and release, the larger your exposure to these extrinsic errors. What it boils down to is risk management - does the benefit of fixed known bugs and outweigh the possibility of introducing new unknown bugs? It all depends on who you're talking to. For a DAW customer, the former; an airline pilot, the latter.
 
Since my time as a programmer was done primarily in embedded control systems, I'm definitely in the camp of fewer releases. The waterfall method of program design and development would be my bible. You wouldn't know it in the Internet age, where bugs and incompatibilities are par for the course. Naturally, this is what the customer wants - no one customer uses a DAW to it's ultimate capabilities and therefore that customer isn't exposed to  the full range extrinsic faults in it. (Except, maybe for us power users....)
 
 

RD9
 
Joe:  I have a 2013 Acme and am unable to shift into 2nd gear.
 

Joe clearly has his priorities wrong.  His car is WAY too new. Imagine the plugins he could have bought if he drove a Datsun 180b.

The 'extrinsic' errors are usually wildly overstated. Almost none of the bugs we talk about on this forum are things that are machine or hardware specific.
 
The 'ship early, ship often' mantra originates from a world where software is made for clients, not end users. The idea is that the client gets to provide feedback long before the final release date so that there's a greater chance of it meeting their requirements, regardless of whether they were able to adequately capture those requirements in a written specification (which they almost never are). The idea is that the client is happier about the software they commissioned because they got to steer it during development and had their concerns met before delivery time.
 
Unfortunately we seem to now be in a world where we use this same routine to give somewhat-broken software to end-users, where the only input they really have is to complain about how it's broken.
 
This is especially damaging in software that has built up cruft and edge-cases, and which really needs some clean-up work doing, as making changes is complex and altering one thing often breaks another. I would bet that Sonar is in this category, given the nature of the bugs that popped up in the last 12 months.