[extropy-chat] Some ideas... dumped

[Emlyn]

On Sun, 15 Aug 2004 20:32:43 -0700 (PDT), Adrian Tymes
<wingcat at pacbell.net> wrote:
> --- 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.

Sure, that's most of coding in my opinion (ie: normal). My experience
is that you either get no doco, or out of date doco, with extremely
few exceptions. These days, I prefer that coders take a simple
approach to begin with, don't bother with too much doco (save for
architectural documentation and maybe a paragraph on each component
(often I mean binary here) of a system, do document funky stuff in the
source code (ie: explain what & why), and basically don't worry too
much about the rest. But writing the code clearly to begin with really
takes the pain away in most cases.

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.


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

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!

Theoretical problems include (1) lots is not infinite (lots and lots
and lots is still not infinite), and even if you get Shakespeare code,
how will you find it in all that muck?

Practical problems include (see own career for reference).

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

I used to think so :-(

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

You can do that. You might have to enforce people maintaining this
stuff, but in the windows world I know that COM objects will do this
just fine (carry big descriptions along with methods and objects).
.Net probably does (haven't dug deeply enough yet, but it certainly
does reflection well), and Web Services do too (although they don't
seem to be object oriented).

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

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

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

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

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

Sure, yes. But that's often easier to fix than people think, as long
as someone is around to calm everyone down. Just don't be scared to
change code.

-- 
Emlyn

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