[extropy-chat] Some ideas... dumped

[Adrian Tymes]

--- Emlyn <emlynoregan at gmail.com> wrote:
> Better to get rid of the idea of team
> leader and go for
> a communcation facilitator, someone who runs around
> (b&m or
> virtually), talks to everyone, keeps an idea of how
> things are going,
> and helps those people who need to talk to actually
> talk.

It's been my experience that that is a good team
leader for engineering projects, when you have
competent engineers.  (The leader also has to make
sure the engineers are competent and not slacking off,
but that's part of what you said.)

> For the most
> part, when two bits of system written by two
> seperate people need to
> talk, they don't really need rigorous API
> definitions imposed from
> above, they just need to communicate, with help if
> necessary. Two
> smart coders can work that stuff out between them.

Is that what you understood?  Sorry for the confusion.
I didn't mean to imply that the boss would define the
API (except in rare circumstances where the
programmers couldn't agree), but rather keep the API
and make sure all the coders know of any changes to it
relevant to their parts.  The API itself would be
built up from agreements between the coders; the
initial draft might be little more than the
theoretical component communications plan that someone
(maybe the boss) thought up when laying out who would
do what.

> I wonder if the thinking goes something like this...
> 
> You can get Shakespeare by giving typewriters to an
> infinite number of monkeys.
> Infinite and lots are pretty much the same.
> Thus if I hire (and presumably shave and dress) many
> monkeys, and give
> them keyboards, I can get the software equivalent of
> Shakespeare
> (after all, it's just typing with the words spelled
> wrong). I can
> replace monkeys easier than real coders.
> 
> Hey, that's a business plan!

I think it's closer to:

This smart guy could build this software.  But he
costs a lot.

Well, what do I need him for?  He's a programmer.  I
can get programmers cheaply this other way.

Such a bargain!  And I can pocket the difference
myself, because everyone knows executives have high
salaries and all sorts of perks.

Money, money, money...hey, what do you mean, you've
run into technical problems?  Don't tell me I need to
spend a lot of money to fix it.  I've already earned
my money.  The business can't afford expensive talent.
You can't fix it?  You're fired!  How hard can it be
to fix this myself?  Well, okay, maybe I need another
grunt to take care of this thing.

...gee, I tell everyone my problem and only the really
expensive guys look at all like they can fix it.  How
dare they charge me so much!  I'll hire them because I
have no choice, but they're rotten people for parting
me from MY money!

And worse, they actually think I'm making mistakes!
They've never run a business; they don't even have
MBAs!  How could they possibly know anything other
than programming?  Even if that one customer who got
around my flunkies the other day and talked to me said
exactly the same thing.  Nah, they've got to be lying.
If they were telling the truth, surely my junior
executives who depend on my good will for their
continued employment would tell me I'm wrong.

(No, I'm not exaggerating.  I speak from sad
experience with too many greedy executives.  I wish it
were otherwise.)

> > 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.
> 
> You can do that. You might have to enforce people
> maintaining this
> stuff,

That's my point: you do have to enforce (at least, if
you've got coders who don't do this automatically, and
not all good programmers know the value of it).
Self-documentation isn't the "drop it in unaided and
watch your problems go away" solution many managers
think is the only thing that would be sold as a
"solution".

> > and
> > certification for each change that all affected
> > parties acknowledge and will comply with it.
> 
> This can be lightweight but should be event driven -
> an email list or
> the kind of emailed notification that lots of source
> control systems
> provide will do the job; how tough do you think
> certification of
> acknowledgement & compliance needs to be? Read
> receipts on the emails
> might do if you are worried.

Better to have a link to click to acknowledge,
especially if you have a distributed project where
you can't rely on read receipts getting through (or
being generated).  You're trying to make sure the
information got into the recipient's brain, not just
the recipient's inbox.

> > 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.
> 
> My alternative to central control is yet again to
> have someone who
> primarily facilitates (subtly forces :-))
> communication.

I think we said the same thing here.