|Jeremy Hylton : weblog : 2003-05-20|
Tuesday, May 20, 2003
Paul Graham's essay Hackers and Painters prompted a long thread on the ll1-discuss mailing list.
I think Paul has a good argument, but I disagree on some of the particulars. The crux of his argument is that programmers are makers, like writers and painters. In particular, Paul's model of painting seems to be the solitary genius model, and that leads him to question whether agile programming made any sense. (The points on which we disagree may have something to do with differences between painting and writing.)
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.
Guy L. Steele, Jr. offered some positive experience on pair programming, although I don't know if extends to common code ownership:
FWIW, the early Scheme interpreters were the result of pair programming (Sussman and I working together, and often trading places at the keyboard). The early Scheme papers were the result of pair writing, where if a paragraph wasn't flowing smoothly from one guy's fingers then the other would jump in with a reformulated sentence.
I don't know if I do much extreme programming -- a particularly hyped agile methodology -- but it's basic practices make a lot of sense to me. It makes sense because it similar to the way I know how to write and because it seems to promote readable programs.
I wrote for my college newspaper, and, in that medium, I found writing to be a collaborative activity. Every story was edited by a least two people, and we usually wrote headlines in pairs. I remember a few productive writing sessions where I shared the keyboard with an editor. Even when I was working by myself, I found it helpful to imagine a conversation between me and a reader.
Paul says that if there is one quote about programming people should know, it is this one from original preface to Structure and Interpretation of Computer Programs:
Programs must be written for people to read, and only incidentally for machines to execute.
In several articles, Paul has argued the easiest program to read is the shortest one. He has a point, but only if you don't push it too far. I think Strunk and White got it right:
Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word tell.
The shortest possible program, however, does not seem like the clearest program in all cases. A short program can easily become a cryptic program that is a puzzle to decipher. So clarity should be the goal rather than brevity. I think comments can do a lot to increase clarity; for example, explaining what variables are covered by a lock or condition variable. If the program is correct, you can figure it out by reading the code; so the information is redundant. But it sure helps to have it written down somewhere. (You may be able to figure it out even when the code is incorrect, as long as it is usually correct. )
It becomes more important to have readable code when you are working in a group. Any sufficiently long-lived project will have many people reading the code, and they need to share some common understanding of what the code does and some common appreciation of good code. (Paul is right on this count, too: taste counts.)
The criticism of common ownership of code on ll1-discuss was that having multiple owners violates the conceptual integrity of the code. Paul again:
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.
I think many of the XP practices are intended to avoid the accumulation of cruft. Pair programming, refactoring, collective ownership, and coding standards all mean that everyone is responsible for fixing bad code.
The other argument is that a system with a single author is more likely to have conceptual integrity. This seems more a complaint about the XP design process -- that having many people modifying the code without serious up-front design is a bad idea. I admit to being ambivalent about XP's approach to design, but I haven't done a project using all the XP practices.
Most of the projects I work on favor some amount of upfront design. The Python PEP process recommends drafting the specification part of the PEP before starting the implementation. Perhaps this would be considered lightweight design because it is fairly informal and it is expected to change once implementation begins.
On the other hand, there's another great quote in SICP that seems an excellent match for XP practices. You often don't know what exactly you're trying to build when you start the design process. So it would be foolish to spend too much time working out the design. Build a little first, then see what you learn from the exercise.
Marvin Minsky and Seymour Papert formed many of our attitudes about programming and its place in our intellectual lives. To them we owe the understanding that computation provides a means of expression for exploring ideas that would otherwise be too complex to deal with precisely. They emphasize that a student's ability to write and modify programs provides a powerful medium in which exploring becomes a natural activity.