Re: [feyerabend-project] May the Source Be With You
- Josh (and Brian too, I guess)-
You might want to take a look at Lion's
commentary on the Unix version 6 code.
It is a tour de force of many aspects of
a "real" operating system, as well as a
review of the particulars of a very early
version of C and its strengths and weaknesses.
A good read, but not for the timid.
But on the whole, it would appear that
most code reviews happen in more
intimate settings (such as CodingInPairs)
rather than in a setting where more people
can criticize the overall concept, design
I've done code review on the job, but usually
only after the person who wrote the code is
gone and unable to answer for it. I have certainly
learned a lot about what *not* to do by that
method. I even have "coding standards" for
C++, Java, and HTML, but it seems hard to
get developers to understand the reasons for
the standards, and to have them take "standards"
very seriously at all.
What I find odd is that even though OO languages
are supposedly easier to "review", programmers
are still rather sensitive to criticism in general.
Perhaps it's because they are given such abysmal
specs and work under such ridiculous expectations
that high-quality work the first time around on a project
is so rare. Perhaps that is why good design is often
the result of good hindsight.
Does this also extend to Open Source projects?
I have seen many comments in the code of open
source projects that clearly show the author has
a tounge-in-cheek attitude about much of the project,
and might not mind a code review, but might not
act on it much either. I'd like to see a work environment
where code review was more of an ordinary fact of
development in general, but it seems that usually
neither managers nor developers get much time to
justify it on the job.
Perhaps a class such as the one you are suggesting
would apply better to senior developers who are taking
on a more managerial role rather than novice developers.
On the other hand, such general skills could be helpful
in speeding up the learning process of novices so they
become senior more quickly. :-)
At 04:57 PM 2/8/02 -0600, Brian Marick wrote:
At 10:59 AM 1/10/02, Gross Joshua wrote:
>That having been said, massive amounts of code (someSomeday, I would like to teach a course on applying techniques of literary
>of it even good code) are available open-source, and
>yet I have never heard of, let alone taken, a course
>that reviewed code, even code produced for the class.
>In textual analysis, we have the technique of
>exegesis. Perhaps we are wholely lacking an exegetic
>technique in software.
>This is certainly true in practice; I've never seen a
>code review where any "close reading" was performed.
criticism to code. (The University of Illinois once let me teach a course
called "CS397BEM: Being Wrong". In those days, they'd apparently let you
teach anything, so long as they didn't have to pay you. The course was a
worthwhile idea, mind you: my goal was to show programmers, via examples
from many fields, how often solutions to problems bring with them new
problems. To make them expect generated problems, not be shocked by them.)
The lit crit course would use a simple text of modern criticism, such as
Tyson's _Critical Theory Today: A User-Friendly Guide" (wretched title) or
Barry's _Beginning Theory_. Some techniques - reader-response criticism,
deconstruction, maybe the new historicism - seem fairly readily applicable.
Queer theory, I dunno.
Given the right five people, it could be a blast. Maybe more of an exercise
in creativity than anything else, but that's OK.
If anyone else does things like that, please let me know.
Brian Marick, marick@...
www.testing.com - Software testing services and resources
www.testingcraft.com - Where software testers exchange techniques
www.visibleworkings.com - Adequate understanding of system internals