Re: the electrix repeater

[Tom Ritchford <tom@swirly.com>]

>My question is: Has anyone at Electrix read _The Mythical Man-Month_?

Now we're getting VERY OT, but I doubt the problems with the Repeater
have to do with the phenomena described in "The Mythical Man-Month,"
which mainly deals with the problem of scale and larger projects.

I doubt that there are THAT many programmers working on the Repeater.
It's not that large a program.  There are parts that are very *difficult*,
like the pitch/time shifting for example, but there just aren't that
many parts you could divide the problem up into!


I'd be surprised if there were more then half a dozen programmers
involved in the Repeater.  I wouldn't be surprised if the number
was four and the technical lead (which is the correct number for
that project -- one person doing the operating system, one person
doing the pitch and time-shifting, one person doing the playback,
and one person doing the time sequencing and synchronizing).


No, I'm sure the problem is that they have built a complex
system and there emergent phenomena of an undesirable nature
(what we call "bugs").

<soapbox>
Emergent phenomena are things that a whole system does that
are not obvious from looking at the separate parts.

They can be good or bad.

Real instruments have both good and "bad" emergent phenomena.
Things like "wolf tones" on a guitar or "throat notes" on a
clarinet are "bad".  Things like harmonics or overtones
are good.

Computer programs beyond a certain size have emergent phenomena
that are almost always "bad" and even just bad like hang-ups,
crashes or corruption.

The reason is that the program world just doesn't force
you to completely specify things in the same way
the real world does.  The programmers make mistakes
which aren't immediately caught because there is no
specification that completely proves the program correct.


Real-time programming is worse.

The programmers have a rough, informal model of
what possible real-time events can occur and when.
But it's kept in the back of their heads and
not completely put on paper.

Since the model is never formalized, you can't
examine it to see if there are any assumptions
about the state of the system that can't be justified.


The solution is painful.  Each section must be
taken apart and completely specified.  Any section
that doesn't have a clear and unambiguous specification
should be taken apart and refactored until it is.

And the entire timeline of possible real-time events
needs to be completely specified so you KNOW
what events can occur, when.

<brag>
I know whereof I speak, because I have done just
this to a real-time Java animation program over the last
eight weeks.
</brag>

BUT I've been programming for a living since 1979 and it's
only very recently I got completely rigorous.

So I know very very well what it's like to have a completely
mysterious bug that you are *never* able to fix...

        /t


<http://ax.to/fortune>.........a new fortune every minute.
<http://FortNY.com>..................Forteans of New York.