>I wonder how much of his argument is related to architecture.  If you have
>a good underlying architecture that supports decoupled development efforts,
>can you go further with unpaid-but-enthusiastic programmers?  From what I
>know of the literature, the data about errors per KLOC (thousands of lines
>of code) is amazingly stable across projects and languages. But I don't
>know how many of the studies have looked at truly O-O projects like Squeak
>and Python.

By def, a better achitecture is better.  A better architecture promotes re-use, both because it is designed for it, and because a "good" architecture typically echoes the structure of the universe in a way that makes it easier to find the piece a piece of code that should be re-used (I am not saying that Squeak is currently a paragon of such perfection ;-).

I doubt that any clarity will emerge on this topic.  Re-use is very hard to quantify.  However it is simple to state the ideal:  every fundamental relationship or process should only be described in one place.  To the extent that something appears in N places, there are N times as many chances to get it wrong one way or another.  Also it impacts testing a lot.  Often when we make a change in Squeak, it gets tested before the browser finishes displaying the change.  Reuse has this ancillary benefit of leverage in testing.

The lines of code thing is just plain confusing.  Generally less is better, and I just don't think you cn compare systems this way.  Consider...

	| strm |
	strm := WriteStream new on: (String new: 10).
	tempNames do: [:n | strm nextPutAll: n; space].
	tempStr := strm contents.
versus...
	tempStr := String streamContents:
	    [:strm | tempNames do: [:n | strm nextPutAll: n; space]].

The streamContents: form encapsulates a variable declaration, a stream creation, and the extraction of a stream's contents.  Every time it gets used reduces opportunities for errors in those places.  And you can be pretty sure that streamContents: is correct, because it has been in use every millisecond for the last three years that the current Squeak image has been running (think about it ;-).

	- Dan