@Article{adelson:81a, author = {Adelson, B.}, title = {Problem solving and the development of abstract categories in programming languages}, journal = {Memory and Cognition}, year = {1981}, volume = {9}, number = {4}, pages = {422-433}, month = {}, keywords = {novice-expert studies, empirical studies of programmers}, citedIn = {Marian Petre and Sally Fincher: Bootstrapping 2002 Experiment Kit}, dateRead = {June 2002}, location = {photocopy}, annote = {Adelson performs a study of novices and experts -- recall of randomly presented code, several iterations -- to argue that experts tend to use functionally-based, hierarchically-organized abstractions (chunks, schemas) for both generation and recognition tasks. I didn't understand Adelson's quantitative measures at all, why they are meaningful and how they support the conclusions. The qualitative data (Table 3) is quite telling, though. The conclusions indicate that experts organize information in memory based on function, and novices based on surface features. My view is that this accords with the work of AGnew and Brown (AB:89a,AB:89b) and also my work on abstraction in AI planning, in that the abstractions provide "functional yet fallible" tacit and implicit partitioning of the world (and hence problem space) that gives the expert leverage on otherwise intractible problems (i.e. programming and program understanding). What is less clear is how experts acquire these abstractions, and Adelson gives no clues. My own hunch is that the framing and partitioning required to even make the chunks, and many if not all of the chunks themselves are socially transmitted, such chunks representing a considerable amount of accumulated cultural knowledge based on the trial and error gambits of predeccesors. This accords with the studies cited in DGG:95a of the work by Dvorak and Moher (DM:91a) indicating that experts have more consistent (shared) abstractions than novices, i.e. we don't make these of whole cloth or first principles. }, refs = {} } @Article{AB:89a, author = {Agnew, N. and Brown, J.}, title = {Foundations for a theory of knowledge}, journal = {Canadian Pschology}, year = {1989}, volume = {30}, number = {2}, pages = {152-183}, month = {}, keywords = {epsitemology, ontology, theory of knowledge, constructivism}, citedIn = {Agnew, Ford and Hayes paper}, dateRead = {June 2002}, location = {photocopy}, annote = {Why do I like this so much? Because they put so much together: decision theory, computationalism, bounded rationality, personal construct theory, evolutionary epistemology, constructivism -- both personal and social. This just accounts for a lot of things that I've read and reflected on -- the best overall take on things that I've yet seen. I love how they use Simon's bounded rationality as a fundamental cognitive/computational constraint, and the parallel that they draw between personal and social constructivism. So what are they doing? They are addressing the central issue of epistemology: how do we know what we know and what relationship does it bear to the ontic world? They use Kelly's personal construct theory as a basic interpretive framework for individual belief -- that it is like a personal Kuhnian paradigm. There are a set of "hidden hand editors" that drastically reduce the search space and frame the world for us. These editors provide us with anticipations (including theories) and we use feedback to confirm these anticipations. These anticipations are highly abstracted, as is our interpretation of feedback from acting in the world. Our anticipations are constructed, our abstractions used in obtaining feedback are constructed, and we tend to seek confirmation of our anticipations while denying negators (damage control). They also address the issue of how these beliefs, though constructed, can be functional, albeit fallible. They also take on how they relate to REALITY. They reject both direct realism and strong relativism. Instead, they see social and biological selection mechanisms that act over time to select quasi-stable abstractions. Such abstractions are most effective in small, artificial, and local worlds, and in worlds with multidimensional, fuzzy, and delayed feedback. They believe that scientific theories may have a better hope of veridical truth than many others cultural/tribal forms of knowledge only because science institutionalizes mechanisms for doubt, testing and systematic evidence gathering. My only criticism is that they don't take quite enough stock in this hidden evolutionary hand. For instance, they say that we "benefit from staking out benign and bufferent environmnents, so too do most of us living in North America, which offers relatively high unconditional probabilities of `success' as compared with base rates in the Third World." (p169) But such environments don't just happen, and we don't go looking for them -- they are engineered, in an evolutionary fashion via social processes over time. Both institutions and artificacts that embed expertise provide "ratcheting" mechanisms for locking in bits of efficiency in the search space -- good designs get carried forward, preserved, and improved upon. Also, they implicitly accept the socio-biological position, which is challenged by the memeticists (I'm thinking of Blackmore's book).}, details = {}, refs = {AB:86a,campbell:60a,campbell:74a,campbell:79a,% campbell:87a,gergen:76a,GM:87a,luce:88a,simon:83a,} } @Article{LC:92, author = {Linn, Marcia and Clancy, Michael}, title = {The case for case studies of programming problems}, journal = CACM, year = {1992}, OPTkey = {}, volume = {35}, number = {3}, pages = {121-132}, OPTmonth = {}, OPTnote = {}, annote = {This is a lovely paper, another of those gems that I have read. Every time that I reread it, I gain new insights. The authors argue that expert problem solvers in a variety of domains, including programming, organize their knowledge into complex structures. Most programming instruction overemphasizes syntax, and students tend to have a syntax based mental representation, which is inadequate for the complex kinds of design decisions that are required for the construction of larger programs. They identify what they call their eight principles of program design that characterize expert design behavior. They then argue that using case studies can help students to acquire these skills. They define a case study as consisting of an explanation of a problem, an expert solution to this problem organized around one or more {\em templates}, and an expert commentary on their solution, which describes the various design decisions, and rationales for these decisions that the expert made. The templates are knowledge structures that include pseudocode that represents the basic action of the template, sample programs that use the template, illustrations to provide graphical reps, verbal descriptions, implementation information sufficient for incremental development, testing information, antibugging and debugging information, and connections of the component to related templates. This paper is extremely well written. It clearly diagnosis a problem: that students do not learn design skills. It presents relevant research from both software engineering and cognitive science as to the kinds of processes and structures that are relevant to the design task. It presents both an abstract description and concrete example of the template structure that it proposes can help to teach design skills. It identifies a number of subskills (the eight mentioned above) that characterize expert design behavior. And it reports on empirical studies that they have made within the classroom, comparing the effect of using the case studies. I find their research completely convincing. I have incorporated pieces of their work into the teaching that I do. But, every time I reread this, I can see that there is far more work that I can do. This paper actually is a lovely companion to the Brooks paper, and it is a shame that they don't reference it. For it is to Brooks more than to Soloway that I think they relate. This is because the design decisions that are being explicated have to do with both the real world domain, and with the mapping between the domain and programs, and the process of constructing this mapping. It suggests that people use much more than plans. On rereading this paper, however, I can see why I was surprised by Clancy's definition of a case study when I took the sigcse workshop. Although I enjoyed his workshop a great deal, and felt that there was merit to it, he never discussed the issue of expert design and commentary. Rather, everything was student focussed, with discussion and meta-analysis. These activities are important, but they do not capture many of the essential qualities that are argued for in the paper. No wonder I was a bit surprised.} } @Article{MNBBK:94a, author = {Lawrence Markosian and Philip Newcomb and Russell Brand and Scott Burson and Ted Kitzmiller}, title = {Using an enabling technology to reengineer legacy systems}, journal = CACM, year = {1994}, OPTkey = {}, volume = {37}, number = {5}, pages = {58-70}, OPTmonth = {}, OPTnote = {}, annote = {I did not like this article at all, and I thought that it was deliberately misleading in several places. I was actually quite confused about what they were discussing: they state: ``This article describes our experience in applying a new enabling technology to automate reengineering a massive legacy MIS system. The enabling technology supports rapid development of tools for analyziing and systematically modifying existing systems.'' So, they are really discussing the {\em enabling technology.} OK, not so confusing. But, how are we to evaluate their claim that they used this to develop a modularization tool that reduced the time to modularize code from 15 person weeks to 4 person hours? This is a difficulty with analyzing a meta-tool, which is what the enabling technology is. It suggests that we have to measure effectiveness of both the meta-tool and the tool that the meta-tool helps us to build. OK. The meta-technology seemed much like the kinds of things described in the previous article. Actually, I'm not quite sure what makes it meta (enabling). What other things can this meta tool do for us? What I really didn't like was their playing fast and loose with these stats - the 4 person hours - really! Indeed, they had invested 4 months to automate the splitting of cobol programs, but they had no proofs that this preserved correctness or that this would save money through decreases in subsequent maintenance costs. The four hours was what was required to set all of the parameters for a particular piece of code, but did not account for any of the time required to verify correctness of the resulting code, test, debug, etc. Nor was there any comparison of the quality of the code at its maintainability as compared to that done by hand. But what really corked me off was seeing that these guys worked for - perhaps owned! - the company that provided the enabling tools. This was a big advertising job! I actually generally support the kind of work that they are doing, i.e., the use of automated transformation techniques. It would not surprise me if things have somewhat improved with the code that they are working on, since the changes that they were making were fairly straightforward. But, they are still ending up with 1000 line code modules (as opposed to 15,000 lines), which are still quite large. You are still ending up with unwieldy, unstructured spaghetti code. } } @InCollection{sahlins:71a, author = {Sahlins, Marshall}, title = {The Intensity of Domestic Production in Primitive Societies: Social Inflections of the Chayanov Slope}, booktitle = {Studies in Economic Anthropology}, editor = {Dalton, George}, year = {1971}, keywords = {economic anthropology, worker productivity}, citedIn = {}, refs = {sahlins:71b}, dateRead = {July 2002}, location = {UWS library}, annote = {Sahlins discusses whether the empirical data from primitive societies support Chayanov's conjecture that "Given an economy of domestic production for use, theory says that the intensity of labor will vary inversely to the proportion of workers in the household. Or, to phrase the rule directly, the greater the relative number of consumers, the more each producer will have to work to provide an acceptable per capita output for the household as a whole. My interpretation of his data is that the data does not fit the theory particularly well. There seem to be sufficient social mechanisms in place to take care of people so that intensity for each worker does not necessarily increase as the number of mouths that this worker needs to feed increases. This pattern is clearly violated in "cephalous" societies, where you have people competing to be the chief. Sahlin's analysis suggests that competition increases productive output per worker, generating increasing surpluses. This occurs in "big-man" villages, with competition being bifurcated: those competing for big-man status tend to have high worker production rates, while those "opting out" of this competition have significantly less production. Status thus appears to come at a cost of personal labor. Looking at the acephaolous (leaderless) villages, I am struck by the different labor productivity patterns. There doesn't appear to be this bifurcation, in particular there is no competitive group. My hunch is that there is less overall surplus (aggregate for the village). Economic competition appears to lead to arms races, resulting in overall surpluses but exacting a labor cost among the competitors.}, details = {} }