Life would be far better if the average person had more pride of workmanship!
We are not talking about a major programming effort here. Making a good Gopher program is far less complicated than (I would estimate) about 80% of the programming currently being done by both amatures and professionals. The creator of the Acorn Gopher Client for example, claimed that he built the Acorn Client in less than 4 hours.
Today, there is almost NO excuse why a single person could not build a near flawless piece of Gopher Software in about a week or two. The real issue here in NOT "can it be programmed quickly and relatively bug-free", but rather "what FEATURES are to be incorporated".
We are not in a market competition that requires rapid software release to stay ahead of the competitors, nor are profits hinging on the rapid realease of software. We are instead striving to get more uses interested in the Gopher Protocol. The critera for that goal is software with "Features People Want", and "Relatively bug-free performance". These goals dictate doing the job "Right The First Time" (NOT quick and dirty programming).
We are only likely to have a potential new Gopher Protocol user examine the protocol and software ONCE. If he doesn't see what he needs (or he sees slapped-together-software), it is unlikely that he will ever examine the protocol again.
--- On Mon, 7/14/08, Jay Nemrow <jnemrow@quix.us> wrote:
From: Jay Nemrow <jnemrow@quix.us>
Subject: [gopher] Re: Item Type Suggestions
To: gopher@complete.org
Date: Monday, July 14, 2008, 3:22 PM
All productive programming is Quick and Dirty. Funny that you use
that Phrase, as QDOS (Quick and Dirty Operating System) was the basis
of MSDOS that stomped out competition quite effectively, simply
because it came to market first (at a good price-point), though it was
technically inferior in many ways. If you ponder too much, consider
all the angles, you will be non-competitive and never get out a
product before the market is already saturated or has blown past you.
You can never do it right the first time. It only gets closer to
"right" as you read your market and make changes to meet needs
(sometimes requiring a complete recoding of things you never
considered that were important). Even though Gopher is not a
commercial product (sure sounds like some people are thinking along
these lines though - "We have GOT to do this right"), it might be a
desire that it meets the needs of a group of gopher-wranglers. New
versions make that happen, as opposed to some mystical, perfect
"first-effort" implementation.
sounds like you had a lot of work incident to y2k. If the originial
programmers had "gotten it right" initially, your job might not have
existed. Perhaps we should be glad for unperfect things that require
our effort in order to get "better" or to "fix" things.
Jay
On 7/12/08, JumpJet Mailbox <jumpjetinfo@yahoo.com> wrote:
> Thanks to the dilligent effort of countless untold computer specialists
(including myself) over a period of several years, our efforts were indeed
successful (but a royal pain none the less).
>
> Fixing Gopher issues I'm afraid, won't generate quite the
response from the community, so we have GOT to do it right the first time... NO
"quick-and-dirty" programming!
>
> --- On Thu, 7/10/08, Avery M. <averym@gmail.com> wrote:
>
> From: Avery M. <averym@gmail.com>
>
> Subject: [gopher] Re: Item Type Suggestions
> To: gopher@complete.org
>
> Date: Thursday, July 10, 2008, 4:44 PM
>
>
> You mean the non-bug?
>
> On Thu, Jul 10, 2008 at 4:34 PM, JumpJet Mailbox
<jumpjetinfo@yahoo.com>
> wrote:
> > Expediency is what always gets us into trouble. Does anyone
remember the
> Y2K bug?
>
>
>
>
>