[extropy-chat] Some ideas... dumped

Samantha Atkins samantha at objectent.com
Sun Aug 22 18:49:23 UTC 2004


On Aug 15, 2004, at 9:31 PM, Emlyn wrote:
>
> I'm going to be inconsistent now and say that I think communication is
> strongly necessary in a development team. But it doesn't have to be
> done entirely by the coders themselves, especially if they aren't
> people people. 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. 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.
>

Yes, but it is a minimal requirement that someone does work out the API 
for the parts to inter-communicate reasonably early.   If N bits need 
to talk then someone needs to put together a workable bit of 
inter-communication infrastructure that the team agrees to use to tie 
the bits together.  It can't just be thrown together and grudgingly 
accepted for each hacker to get own with his/her bit.   It is 
effectively a joint context within which the rest will be done.    Get 
it wrong and it won't matter how brilliant the bits are.  Many large 
systems bite at this level.

Also, not all genius hackers are created equal.  Some of them are great 
on the "bits".  The rarer ones are good software architects/system 
designers.   Good design esthetics is a rare commodity even among 
brilliant hackers.     This stuff is even harder to get management to 
recognize.
>
>>
>>> 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,
>
> Yes, I agree with this. Top level stuff is most important; which bits
> talk to which other bits and why (how is also good, but less
> important).

Language determines thought to a seldom appreciated degree.  The how is 
language.  Get it wrong and the system becomes clumsy and limited.

>
>
>>  For
>> large groups, this can be done semi-autonomously - if
>> (and only if) the involved parties can agree to it.
>
> I guess I've addressed this above, I agree. It depends on the task
> too; an interface between two components is easier to negotiate ad-hoc
> than an interface used by half of the teams in an organisation.
>

Yep.

>> 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.
>
> I never like this, because people are too likely to let the api be set
> in stone and kludge around it rather than changing it when necessary.
> A good principle to keep in mind is the ability to extend your api
> without breaking old stuff, covers a lot of the ground of adapting
> your api.
>
> My alternative to central control is yet again to have someone who
> primarily facilitates (subtly forces :-)) communication. You can call
> this person team lead, or head chat monkey, it matters not. But the
> role is kind of coach/mentor/facilitator, and requires a really good
> communicator (who is also technically competent if not excellent).
>

Communication alone is not enough.  You have to recognize that some 
people are good at system wide architecture and others are not.  You 
have to have the former create the weave the rest use to connect their 
modules and work within.  There really does need to be an overall 
architect that does the deep thinking about the whole beast not only in 
relation to current requirement but in relation to its ease of 
maintenance including possible future evolution and entanglement with 
other systems.    Very few think at this level.  Even fewer 
organizations both understand and support this level of thinking and 
design.

It is not enough to have everyone just talk to each other.  Not by a 
long shot.

- samantha




More information about the extropy-chat mailing list