Not sure where this would really go, but I’m curious, so I thought I’d ask.
Is it possible to ever fix every single bug in a piece of software? Or are new bugs created constantly through updating and the fixing of other bugs? Should I ever really look forward to a day when updates aren’t really needed?
Not a serious question necessarily, just food for thought?
I think it’s a bit like asking: can a human ever be truly healthy? 
It’s not technology that is in flux. Rather it is the convictions we place upon technology, and the demands we expect of it that are forever changing.
It’s probably not ever possible to be completely bug-free, because the OS is always getting updated, and Apple and Microsoft introduce their own bugs with each release. But updates aren’t only about bug-fixes - they are also about refining what’s there. With prolonged use (in the case of Scrivener, both by users and by myself and the rest of the team), it becomes easier to see how different features can be better integrated, or how certain elements might be refined or made easier to use (let alone seeing the potential for additional features).
And that goes well beneath the operating system (and programming toolkits) as well. Remember the infamous Pentium floating-point bug? The chip itself was returning incorrect answers and that’s such a big deal that Intel had to recall a huge batch of CPUs during a flagship launch.
But yes, software is only the most obvious knot of logic in the huge tangle that is “your computer”, it is not even easy to distinguish between running software and the environment it runs within. There are trillions of moving parts, just running electricity through it changes it, such that we can say it is not possible to type the same letter twice—to update a proverb. 8)
Such are the joys of development!
“You cannot grep into the same string twice.”
-gr
Bug Free No, it is goal that everyone strives for, but no one will ever obtain.
What you want, as a consumer of software others write, is a dev team that can respond to the wave they are riding, like a pro-surfer. If they can’t, you will be sitting there with a tool, that would be harder to use than a hammer and chisel on the walls of the tomb. (The Egyptians didn’t have Control-Z key.)
Updates are a fact of life, like death and taxes.
Those who cannot read and therefore surf the wave of change, are wiped from the wave, their software becomes yet another bone in the yard.
So Updates are a very good thing, it is when the updates Stop, you should start worrying.
There is a saying among programmers that every program has at least one more line than it needs to, and has at least one bug. The corollary, of course, is that every program can be reduced to one buggy line.
A lot of software does reach the point where the number of bugs is small enough, and the situations that trigger them unique enough, that most users will not encounter bugs. Usually this happens right before the next version comes out…
Nor, as Keith pointed out, are all updates due to bugs. There have been updates to Scrivener for Mac in order to improve compatibility with Scrivener for Windows. There will be updates in order to support Scrivener for iOS. Technology becomes more capable, and so software is asked to do more in order to exploit those capabilities.
Katherine
I used to write software back in the 1980s and yes, it was possible then. In fact, two of the utilities I wrote ended up bug-free. It took two years for one of them, an animation file converter for the Amiga, and that was with no new features being added. Of course, it was feature-complete to start with.
These days, though? Not frickin’ likely. 
I’ve heard some mainframe software is functionally bug free. Mine you we’re talking programs written in COBOL that were started in the 1960s and the same code base was debugged with virtually no new features for the next 40 years. The last time some of this software was touched was for Y2K compliance and then it was shoved back into a black box and forgotten about again because it “just works.” Think banking, utility billing, airline reservations, university scheduling, etc. the kind of stuff that hasn’t changed much in decades.
Some of these mainframes have truly bizarre architectures, too. Like they’ll run custom-designed, massively multi-core CPUs that can handle truly godlike amounts of RAM and storage and insane clock speed and enough I/O and network bandwidth to transfer half the Internet… to run software written for a mainframe that came out in 1964.
Unfortunately, this is also part of why you might have an online banking password that’s only 6-8 characters long that can’t use any symbols.
The late Edsger Dijkstra a founding father of computing science once remarked that “software testing can never prove the absence of programming errors only their presence.” It is trivial to set up a case for Dijkstra’s opinion with a sequence of program code containing a few loops within loops and a couple of conditional statements (if/then/else). When there are millions of repetitions and multiple paths through the code the time to test exhaustively will tend to infinity.
However that only deals with the problem of code errors. It can never deal with the more general reason for “updates” that of new features being added to the program; for example, while I’m sitting with v2.6 on Mac when Scrivener for iOS is released I will have to get an update so that the Dropbox synchronisation features works correctly on the two devices. (Actually three devices as I have Scrivener on my Mac and will run it on both my iPad and my iPhone.)
The only way software can be bug free is if it’s declared ‘feature complete’ and then all the bugs are tracked down and stamped out. However, the hunt is liable to take a long time (years, likely) and the OS it runs on would also have to be declared feature complete and all remaining bugs in it would also have to be stamped out…
Short answer: no.
