Re: PG: Hackers and Painters

[Matt Curtin <address@hidden>]

Paul Graham <pg@archub.org> writes:

> 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.

I think a lot of it probably has to do with how well you know the
other, and how much you trust each other.

A few years ago, I worked in a completely crazy project, where we had
to create a means for university students to write XINU code in a
multiuser Solaris environment.  In the end, we wound up creating a
userland library against which students would link that would provide
all of the XINU interfaces that they were expecting, along with some
safety controls in there so that people trying to implement remote
filesystems with UDP wouldn't take down the network by UDP flooding
the network.[1]

Another hacker and I were assigned the illustrious task of doing the
job, and we were given, literally, three days to get enough of it
implemented to assign the first laboratory assignment.  This was not a
trivial task, either, because some of what we had to implement in
multiuser Solaris didn't really make sense in that environment, at
all.  Largely to make the system as small as possible so that in a
very short time a student can understand the whole thing, XINU
implements some things in strange places.  (A command interpreting
shell is kernel code...)

We decided that we really couldn't afford proper pair programming, and
decided to carve the job into pieces: he would implement one part and
I would implement another.  But we shared lab space and the whiteboard
and whatnot, so anytime that one needed to bounce an idea off of the
other, he'd throw out an interrupt.  After each of us would finish
some implementation, the other would review and even make changes to
the others' code.  This worked remarkably well.  I attribute this to
several things though:

 o We are both insane about making the code look the right way.
   Functionality is perhaps forty percent of the problem.  Style
   counts.

 o We agreed on a style at the very beginning, and wrote Emacs macros
   that would put the appropriate style-setting tags into the files as
   they were created, so no matter what we had set for our personal
   preferences before, we were certain to use the same preferences
   while we worked on that project.

 o We respect and trust each other.[2]  There aren't a lot of people
   with whom I trust my code, but I had the good fortune to work with
   such a person on that project.

I don't know if this kind of thing can be generalized or turned into
some kind of lesson that we can use, except perhaps this: small groups
of hackers can do amazing things, but success depends at least as much
on the ability to work for the success of the team as much as it does
the individual hacker's skill.  I think a corollary would be that
teams must be assembled not only on capability, but sense of style and
other kinds of compatibility that would never occur to most program
managers.


Footnotes: 
[1]  As an aside, I saw some truly sad code when looking at what
     students were actually doing with the library.  Things like:

         while (1) {
            do_some_stuff();
         }

         printf("Got here!\n");

     I am not making this up.


[2]  This is true, even though a review of a file containing excerpts
     from the conversations had during that hackfest might suggest
     otherwise. :-)

     Heard Thu Mar 30 02:30:09 EST 2000 after discovering the source
     of a heisenbug in the C code:

       cmcurtin: I don't suppose now would be a good time to talk
                 about the virtues of Lisp.

       rowland: Hey, you're the one who fucked it up.

-- 
Matt Curtin, CISSP, IAM, INTP.  Keywords: Lisp, Unix, Internet, INFOSEC.
Founder, Interhack Corporation +1 614 545 HACK http://web.interhack.com/
Author of /Developing Trust: Online Privacy and Security/ (Apress, 2001)