[extropy-chat] Some ideas... dumped

[Adrian Tymes]

--- 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'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.

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.

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).