[extropy-chat] Some ideas... dumped

[Emlyn]

On Sun, 15 Aug 2004 16:13:34 -0700 (PDT), Adrian Tymes
<wingcat at pacbell.net> wrote:
> --- Emlyn <emlynoregan at gmail.com> wrote:
> > One is a concept of web-based identity management
> > for people out in
> > the world, to handle all the myriad email addresses,
> > web site logins,
> > files, calendars & schedules, contact lists, etc,
> > etc, etc that we all
> > accumulate but that get completely out of hand
> > (because there's just
> > so much heterogenous crap to remember, like
> > usernames/password, or
> > urls, or whatever).
> 
> Been done.  Google doesn't just have search results
> for this, it has a bunch of ads from providers.  The
> main flaw: unless you own the servers, someone else
> owns the machines your identity resides on.  How much
> can you trust them?  (Granted, there's some of that
> even now.  This is a lot more.)

I had a private email to me pointing me to one of these. I must check
them out, see how closely they match what I'm imagining. If they're
good, I might try using one, and I'll let people know how it turns
out.

> 
> > I'll expound shortly on a half baked software
> > development methodology
> > that I've got brewing in my head, tentatively tagged
> > "disposable
> > code". The axioms are "assume you start with a few
> > spectacular coders,
> > genius hackers, who can kind of work together, are
> > individually
> > irreplaceable, and most of whom don't like working
> > with each other.
> > What can you do?". It's a reaction to the regular
> > methodologies
> > (standard big system & agile) which assume that you
> > want to work with
> > endless fields of stupified code grinders, and that
> > the brilliant
> > cowboys in the corner are a liability...
> 
> The brilliant cowboys, like anyone, could get sick or
> quit - especially if you (the business manager who
> can't see anything but $) try to reduce their high
> pay so you can pocket more profits.  Cheap code
> grinders are widely available, and you still have the
> code even if its makers quit.

I'm well aware of the problems with using excellent people with unique
skills/talents (rather than cookie-cutout grinders), but I think those
problems can be ameliorated using the right approach. Mostly it's all
variations on the theme of modularity.

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. I think,
given that most of our systems are built on a lot of this crazy magic
code built by these guys (imo), it might be better to not throw out
the baby with the bath water, and instead find a way to work with
them.

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

> 
> In reality, high-quality businesses require truly
> trusted employees.  But try telling the paranoid
> execs who have fought off all manner of cold-blooded
> challengers to their business.
> 

Yup. 

> As to this question itself, the answer is pretty
> standard, if not often applied within a single
> business unit: divide the application into each
> person's responsibilities, and make a solid API.  If
> someone needs a new API, they can negotiate for adding
> it; the executive managing the project is responsible
> for maintaining the API document itself, as part of
> the project management documents (like the task
> breakdown and schedule).  Otherwise, each programmer
> is responsible for making sure their bit meets the API
> perfectly (along with other, part-specific
> responsibilities: databases don't lose data, UIs are
> usable, and so forth).

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), and distributed systems
composed almost solely of loosely coupled small pieces, so that the
overall central control of the api is less necessary, and so
individual pieces can be replaced almost at whim. There's more to it
than this... I must sit down and blog this thing.

-- 
Emlyn

http://emlynoregan.com   * blogs * music * software *