I think the level of bugginess depends a lot on the expertise of developers, their rigour and the philosophy they adopt.  If you set out from the very beginning to produce solid software there'll be far less bugs than if you have inexperienced programmers just throw together code to address a need and figure that'll you'll address any bugs later on as users discover them.

and let's not forget, it's not the devs or the end-users who decides which bugs get fixed ;-)

I think one of the takeaways from the article is that fixing bugs is an iterative process. I don't write software, but I can relate because I write words. My first drafts usually suck; there are loads of "bugs." So I do an edit, and quash most of the serious ones, like typos, bad flow, etc. Then I do another edit to clean up phrasing, and try to find statements that can be interpreted in more than one way. Then it gets down to a comma here, a semicolon there. Eventually, I find no more issues to correct, and then submit the article for publication. 
 
However...if I re-read it a year later, I see things that could have been said better, and I think I should have done another edit.
 
The problem is that software is written by humans. As long as there is human error, there will be software bugs, car accidents, missed appointments, football fumbles, plane crashes, automobile recalls, unanticipated side effects from drugs, botched appliance installations, etc.
 
Come to think of it, software doesn't have bugs...humans have bugs that get transferred to the software 
 
 

Having read a large number of your writings, there must not be very many bugs because I keep reading them.

Anderton
I think one of the takeaways from the article is that fixing bugs is an iterative process. I don't write software, but I can relate because I write words. My first drafts usually suck; there are loads of "bugs." So I do an edit, and quash most of the serious ones, like typos, bad flow, etc. Then I do another edit to clean up phrasing, and try to find statements that can be interpreted in more than one way. Then it gets down to a comma here, a semicolon there. Eventually, I find no more issues to correct, and then submit the article for publication.

What you describe are not "bugs". That are "hard to use interface" for visible part and "not optimized algorithms" in invisible part of software. Can be annoying, but as with typos and bad flow (which for sure you could already notice in my bad English...) you read throw and move on.
 
A "bug" will be to write "LANRD is a VST for Sonar"
 
I normally try to avoid any code modification ("never touch running system") when it produce correct result. Unlike an article, close to no one is interested how good or bad the code is written. That is important difference between these two "arts".

Anderton
I don't write software, but I can relate because I write words.

the only similarity is the typing

Anderton
I don't write software, but I can relate because I write words.

Except that generally the impact of bugs in writing is to produce soft failures. In many, many cases, it is easily possible for the reader to work around the bug with little-or-no loss of meaning. (This is not true when the material in question is mainly communicating data, especially numbers, of course.)
 
Even when I type quickly and make mistakes, you can provaly still get whta I intended.
 
Bugs in software (at least, the ones that get us exercised) typically produce hard failures and stop the show, or ensure that the desired end result cannot be achieved.

My premise wasn't that writing words was the same thing as writing software. The premise was in the first sentence, about an iterative process. 

Anderton
My premise wasn't that writing words was the same thing as writing software. The premise was in the first sentence, about an iterative process.

It is too generic then, with the "production cycles" (not only in Software) approach.
 
But if we take one practical example.... MIDI FX in Sonar. Implemented with problems and it looks like with some bugs, at least before 2003. Still there, unchanged, 2016

azslow3
But if we take one practical example.... MIDI FX in Sonar. Implemented with problems and it looks like with some bugs, at least before 2003. Still there, unchanged, 2016

And I'm sure it could be redone from the ground up and not have any bugs at all.  It's not like a mission to Mars.