Finished Software is

Software is a form of mathematics; too many fools are ignorant of this simple fact, and the state of
software has them believe perfect software to be a myth.  Perfect software is finished software, for
to perfect something is to finish it.  We get the word ``perfect'' from Latin; a form of the verb to
finish, PERFICERE, is PERFECTVM; the word ``finish'' is also from Latin, the noun FINIS meaning end.
If software meets its specifications exactly, then it's finished, and therefore perfect; the current
trend is to finish anything, never, for then malicious changes called ``updates'' may be forced onto
others perpetually, which is another Latin word, PERPETVVS, meaning endless.  Any idiot who believes
finished software to be a myth is stating his inability to finish anything, and ought to be avoided.

Finished software is obvious.  Consider a program that does nothing.  Fools who worship at the altar
of UNIX think very highly of software that does nothing, although some does it more efficiently than
others.  Next consider a program that does something useful, such as adding positive integers modulo
some limit.  Such a program can obviously be finished, and anyone who disagrees is lying, or stupid.
If any software can be finished, perfected, and any can, then it stands to thought that all software
can be finished, although many a modern program's so grotesquely complicated and poorly specified to
effectively prevent this, simply because no one knows exactly what it should do, but most software's
not complicated so; there's not much of a point in trying to finish software that should be trashed.
It stands to thought, as software is recursively built from smaller software until reaching bedrock.

Finished software requires a finished context.  This is why it's easier to write a video game for an
abandoned video game console than on some newer platform.  There's a valid point to be made that the
interfaces used by modern software are a poor foundation, and I'd agree this is at least half of the
problem.  One solution is to use foundations independent of this poor current state.  An APL program
will be finished forever, as will any other program with a mathematical bent and proper abstraction.

Software isn't physical and thus isn't subject to the rot or decay which affects most or all things.
Programmers love to speak out of both sides of their mouths on this, by arguing that they're akin to
bridge builders forced to change building materials halfway through construction, and simultaneously
arguing that they shouldn't be held to similar standards, like customers expecting software to work.
Such physical analogies begin and end whenever convenient, and it's clear there's no clear thinking.

At the least, proper interfaces can be designed which require very little maintenance to cope with a
changing world.  Almost all software can be designed to use some nice abstraction to support itself,
and those abstractions can use yet deeper abstractions, until only a very small amount would need to
be touched whenever some extreme change occurs; stability isn't the end of the world, but its start.

I was spurred to finish this article recently, but it may collect some new ideas before I finish it.
.