From Slashdot This Morning

[Anton Vredegoor]

Robin Munn <rmunn at pobox.com> wrote:

>Original URL for Paul Graham's article quoted above:
>
>    http://www.paulgraham.com/hp.html

from this url:

>> As far as I know, when painters worked together 
>> on a painting, they never worked on the same 
>> parts. It was common for the master to paint the 
>> principal figures and for assistants to paint the 
>> others and the background. But you never had 
>> one guy painting over the work of another.
>> 
>> I think this is the right model for collaboration 
>> in software too. Don't push it too far. When a 
>> piece of code is being hacked by three or four 
>> different people, no one of whom really owns it, 
>> it will end up being like a common-room. It will 
>> tend to feel bleak and abandoned, and 
>> accumulate cruft. The right way to collaborate, 
>> I think, is to divide projects into sharply 
>> defined modules, each with a definite owner, 
>> and with interfaces between them that are as 
>> carefully designed and, if possible, as 
>> articulated as programming languages.

Although I think this is a great article, there's always the danger of
some very smart person first saying some sensible things and following
this by completely unfounded and utter nonsense. 

In this case it's highly likely that the author is fighting math-envy
but is at the same time infected by it on a very deep and unconscious
level. What else could be the reason for wanting to "divide projects
into sharply defined modules, each with a definite owner" than to
perpetuate the basis for everlasting math-envy? 

As logical as it seems to be to conquer complexity by smartly dividing
it into manageable subproblems, the corollary of assigning each of
these specific subprojects to a specific person is very detrimental.
This is the way things are done everywhere so it seems impossible to
escape this "natural order".

What's so bad about it then? For one thing, although we live in a
world where "intellectual property" rules, there is no such thing
discernable in the way ideas are created. We don't own our ideas
anymore than the air we breathe or the land we live on, except for the
guns and weapons used to defend it.

How often have I thought to be the source of an idea only to later
find out that I'm only unwittingly plagiating some author unknown to
me, who's ideas have been translated to me through some unknown
memetic vector? 

Also a case could be made that although sometimes the code that I
"produce" will be negatively "improved" by the next code refacturor,
the net effect of all these transformations is better code through
something akin to a "genetic drift" towards better and better code.
I'm not saying that massive amounts of infertile code couldn't stall
progress, but that's something completely different. 

The right way to collaborate is to exchange and improve code snippets.
Refactoring Grahams analogy: It's better to tolerate people living in
the common room, and just stimulate good and healthy coding
practices.[1]

Anton

[1]  Always keep a tamper free local copy of the code, of course. :-)

--

Dijkstra didn't know what he was going to say before he spoke.