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

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

 
I fixed that for you 

Interesting forum.  Is the timing related at all to the number of bugs in the latest version of Sonar?  I haven't downloaded it yet and was wondering if I should hold off a bit longer. 
 
As some of you have pointed out, it can take a bit of time to find and correct the bugs in software (as well as written text).  That is why I continue to suggest that new elements be introduced quarterly and the intervening months be used to tidy things up.
 
Cheers.

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.

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. 

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.

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 - What I struggle to understand is how a philosophy/methodology that depends upon the open source model, necessarily applies to paid-for, closed software like Sonar. The mantra "Given enough eyeballs, all bugs are shallow" simply disappoints someone who only can see the symptoms of the bugs. You see the effect here quite often, when intelligent, committed people are reduced to mere speculation about the cause of a bug, because without the sources and the skill to interpret them the software is a black box. That is not to denigrate the many experts in this forum (nor is it to criticise Sonar itself) BTW.

The three sentences in the first paragraph alone of that link have issues with what users are experiencing IMO.

1. Users are beta testers (actually paying to be such), yet are met with more roadblocks rather than highways for feedback. For a typical issue, I would assume 1-2 hours is spent just in the "report/recipe" phase, let alone all of the push back received.
2. Feature requests/feedback is met with workarounds more often than not (i.e., can do that now!). Users are diverted to the Feature Request forum as an "official pathway," and it is growing faster than collapsing.
3. "Creating [features] that no one will use"... not sure whether to laugh or cry about this one TBH.

subtlearts

Kylotan
"Man who makes money by writing software wants you to stop complaining that it isn't good enough".
 
Excuses.

Disagree. Man who has a long track record writing useful software, running successful software companies, and writing influential bestselling books about software and business, and arguably understands these things as profoundly as anyone, explains his viewpoint - backed by all of that experience - of how software developers and companies (at least those likely to stay in business) view the subject. You think he's whining, so we should believe you? Riiiiiight. 

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.

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.