Re: PG: Hackers and Painters

[Eric Kidd <address@hidden>]

On Wed, 2003-05-14 at 13:19, Paul Graham wrote:
> 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.  

Your question is more about XP, than about "agile" methodologies in
general.

* Test Driven Development

A truly good thing.  It gives you clean APIs and minimalist
implementations.  What's not to like?

* Collective Code Ownership

Collective code ownership is an enormous win among hacker types, in my
experience.  You can fix the bugs that need fixing, or improve the
interfaces between layers, without needing to disturb somebody who's
hacking on something else.  Granted, there are some people I don't want
redesigning my code, but in general, I find that such people botch
everything they touch, and shouldn't be on the project in the first
place.  Private code ownership often means, "Assign the losers to
modules where they won't do much damage."  It's probably better if you
can avoid hiring the losers in the first place. ;-)

* Pair Programming

I haven't pair-programmed much, but I've typically enjoyed it,
especially for complex (but not necessarily *deep*) problems.  It's a
great way to move information around a team, and you tend to catch
design problems quickly.

Pair programming is definitely good for XP-style programming: "Refactor
this to here, write some tests, use that pattern there, extract a
superclass, etc."  XP assumes that you can solve most design problems
using a hill-climbing algorithm and a ruthless dedication to
simplicity.  For 95% of the world's design problems, this is probably
correct.

But there's another class of problems which require truly deep thought. 
Heavy macrology, heuristic approximations to NP-complete problems,
language design--anything where hill-climbing in design space will take
forever, or leave you stuck on a local maximum.

For the truly difficult problems, I mix hard thinking with lots of hill
climbing.  And under these circumstances, I'm not sure I could pair
program.  I prefer to use colleagues as a sounding board, and make the
big decisions myself.

For me, the big surprise of XP is how well hill-climbing in design space
actually works.  It's not a universal panacea, but it's taught me a lot
of humility--many problems aren't nearly as hard as my brain wants to
make them.  I can just write something ridiculously simple, refactor and
extend it as needed, and wind up with a simple, clean solution.

Cheers,
Eric