[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PG: Hackers and Painters

I personally like to have my own sandbox, and have other people suggest
improvements.  There's a danger that when everybody owns the code, nobody
really cares about it much.  But I could imagine that if I had sufficient
respect for my collaborators that it might work with communal ownership.


> Date: 14 May 2003 17:19:50 -0000
> From: Paul Graham <pg@archub.org>
> I've heard of this agile programming thing.  (Surely "agile" isn't
> the best word, btw; surely one hacker is at least more *agile*
> than two.)  There may well be cases where several people can work
> on code.  I don't think I could, though.  It's fine to have code
> reviews.  Such code reviews could even take the form of presenting 
> someone with a rewritten version for them to adopt if they chose. 
> But I don't think I could stand more than that.  Nor would I 
> presume to do more than that to code someone else owned.  
> Maybe I'm just an old crab though.  Does anyone on LL1 have
> any opinions about this?
> --pg
> --Ken Anderson wrote:
> > At 07:39 PM 5/8/2003 -0400, Geoffrey Knauth wrote:
> > >Saw this on Slashdot:
> > >
> > >http://www.paulgraham.com/hp.html
> > >"Hackers and Painters"
> > 
> > I had passed by Paul's site several days ago and started reading it.  I agree with most of it, for example Yugoslavia, and i marked up several key points - It should be a pencil, not a pen.  Scribble, smudge, and smear describes what i do best.
> > 
> > But i disagree with this paragraph:
> > "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.
> > "
> > There is an alternative to the common room feeling now.
> > Several ideas of extreme programming, which you can follow more gently, and call an "agile method", are:
> > I1:  no one owns the code.
> > I2: anyone can refactor any of the code when they need to add behavior.  refactoring means, reorganize the code so it is easier to understand and provides the capabilities of the previous version.
> > I3: pair programming allows multiple people to contribute to the design of a module.  I've seen our most junior pair programmer help my code and even make it simpler.
> >