[extropy-chat] Some ideas... dumped

[Adrian Tymes]

--- Emlyn <emlynoregan at gmail.com> wrote:
> People have been slagging off the loner coders for a
> long time now,
> you know, those mad geeks who can't communicate but
> can churn out
> magic code that no one else can, and no one can
> understand.

*cough*  And the more I see the reality of that
stereotype, the more I see it to be false.  Maybe I am
one of those mad geeks, but so long as I have the
source code, I've been able to reverse engineer any
system I've tried to.  That has, in fact, been a
necessity on some of my jobs, due to sheer lack of any
other documentation.

Then again, people like me tend to charge a lot for
our services.  Businesspeople sometimes call something
"impossible" when it's actually just "impossible to do
really cheaply".

> btw, I don't think the grind method is necessarily
> wrong, I just think
> there are valid alternatives.

Ditto.  There are times when non-trivial costs are
justified - mainly when the potential profits are even
greater.  (One would think businesspeople would
understand the concept of "investment"...)

> That's the kind of thing I'm thinking of, but I've
> got a mad idea
> about self documenting APIs (think web services, but
> promoted to the
> level of abstraction of a java space),

Been there.  Done that.  Self-documentation is a nice
start, but unless you have some way of conveying the
meaning of each thing (at a minimum, well-chosen names
instead of stuff like "double doShmoo(short a, short
b, float x)"), it falls flat on its face.

> and
> distributed systems
> composed almost solely of loosely coupled small
> pieces, so that the
> overall central control of the api is less
> necessary,

You don't directly need central control of the API.
You do need a central document source, and
certification for each change that all affected
parties acknowledge and will comply with it.  For
large groups, this can be done semi-autonomously - if
(and only if) the involved parties can agree to it.
But as you said, this is for a project where the
independent coders don't talk to each other very well,
thus the need for central control: to facilitate
communication and make sure some agreement is reached.
Otherwise, you'll have coder A working to his version
of the API and coder B working to her version, and
find bugs where the two versions conflict.  (Say, if
coder A figured out that doShmoo() only returns
positive integers, and thus changed its type to int,
but coder B was doing bit-shifting tricks with the
result that only work for a double.)