[Namaste-dev] Re: Weekly Plan June 2 - June 6

Frank Brickle brickle at pobox.com
Wed Jun 4 07:57:50 PDT 2008


On Tue, Jun 3, 2008 at 1:25 PM, Paul Williamson <kb5mu at amsat.org> wrote:


> Well ... maybe we don't agree so completely as all that.


Perhaps you're right, although I don't really think so.

For example,


> I AM sorely tempted to say that I do advocate mandating some aspects of the
> development process. If I were in a rabble-rousing mood, I would say that I
> want to mandate "engineering" and prohibit "hacking".


...I have no idea what this means, except in a whimsical sense like, "I want
to mandate always getting it right the first time and prohibit having to
change strategy in the face of obstacles."

This is a production development project we have here, or so we hope, not an
> experimental R&D project, to whatever extent it's meaningful to say that
> about an amateur radio project.


...or here, where we have a categorical statement of policy whose genesis
was anything but transparent, and seems to me to be actually incorrect.

That kind of design often works well for *implementation*, especially of a
> fairly localized item like a computer program.


...or here, which expresses a reasonable limitation, except for the universe
of counterexamples ready to hand, such as TCP/IP or email or 802.11 or,
even, APRS.

I think the point is -- and I think you'd agree -- that certain parts of
Namaste are vulnerable to "engineering" and certain parts aren't. For
example, a surprisingly large part of the software work involves protocol
design and implementation, not APIs or functional descriptions of code
modules or, in fact, implementations. There are big chunks of the project
which are still in the discovery phase, so to speak, and, more importantly,
will be for the entire lifespan of the project, by design, and as they
should be. (That's why I question the "production and not R&D" statement.)

What's the point of having so much of the project in software, after all?
Precisely because software is programmable, mutable, dynamic, and capable of
being re-targeted in the face of novel situations. Software is the ultimate
hedge against engineering hubris.

A subtle eye is needed to discern which parts need blueprints and which
parts need horticulture. Something which the Namaste team as it's
constituting itself is fully capable of, by the way, I'm pretty sure.

One personal gripe, though -- how does any of this turn into not wanting to
produce documentation? The issue is what kind, not whether.

73
Frank
AB2KT

-- 
The only thing we have to fear is whatever comes along next. -- Austin Cline
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://amsat.org/pipermail/namaste-dev/attachments/20080604/663c069a/attachment.html


More information about the Namaste-dev mailing list