[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PG: Hackers and Painters
I agree completely. The whole "Extreme Programming" thing -- at least the "team coding" part -- never appealed to me. Shades of collectivist thought -- "the days of the individual programmer going it alone are over...assimilate into a Borg unit and code together!" Bah! I'm sure there are people whose personalities are amenable to that; not me. I think you'd get more "agile" coding by allowing individuals to code the same module independently and competitively, and have them try to one-up each other in stability, performance, functionality, etc., and may the best code make it into the final product.
At 05:19 PM 2003.05.14 -0000, Paul Graham wrote:
>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?
>--Ken Anderson wrote:
>> At 07:39 PM 5/8/2003 -0400, Geoffrey Knauth wrote:
>> >Saw this on Slashdot:
>> >"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.