I am a senior lecturer in the Department of Computing and Communicatons at the University of Lincolnshire and Humberside. I have taught here for nearly 9 years. My main interest is in the teaching of structured programming to novice programmers. I am currently researching ways to support such programmers using various resources including an on-line help system that parses queries and returns a best match answer. I am looking at the simplest systems possible so that even those not confident in computing can use the resources appropriately. I have explored other approaches and would welcome any comments, ideas that people have in this field.
My interest comes from the fact that I did a conversion MSc in computing, having taught English for five years in the state system. I have been that novice programmer and believe that much can be done to ease that early cognitive burden.
Greetings fellow PPIGers:
I'm finally getting near to finishing my PhD dissertation. The current working title is "Tool Support for Software Engineering: A Distributed Cognition Framework". In case you haven't talked to me about what I'm working on, I've taken aim at the poor state of psychological analysis and justification in software maintenance and reverse engineering tools. I'm trying to raise awareness of such psychological issues within the software engineering and computing science community, but as many of you know it is not an easy sell. I believe headway can be made by developing a very application-oriented theory of cognitive support, and by making it demonstrably relevant to the cognition-related questions they're currently researching and working on.
One of the most serious questions we/they ask is "what makes a program comprehension tool any good, cognitively speaking?" As I'm sure you all know, we do not have many satisfactory answers for that question. There's some empirical work (hey this tool works!), but rather little theoretical work (...and here's why). The problem isn't just lack of good theories or applicable ones, although perhaps there are too few for eveyone's liking. The problem is that direct argumentation about cognitive support just seems to have slipped through the cracks in HCI and cog sci theory development.
I've found it embarrasingly easy, for example, to argue that most theoretical work in HCI has been oriented towards problems exhibited by existing tools, not the good things it provides for the problem solver. Most applied theories are currently (under-)employed in the rather menial jobs of predicting problems like inconsistency, difficulty of learning, unwanted viscosity, hidden dependencies, and so on. Some also have jobs setting basic design goals (reduce cognitive burden...some how), but these fall short in their ability to generate design ideas.
How are you supposed to design good tools if all you've been told is how to make bad ones? Its like trying to find buried treasure with a map that tells you only that its not buried in London. In the theory-as-map metaphor, I want a theory to at least give me hints as to which area of the globe to start looking in. If I come to the theory with a problem with software development it should speak to me about what support can be offered to ameliorate the problem. Right now, with few exceptions, all we have in this department is experiential or craft knowledge, not theory-based knowledge.
The philosophical backdrop of my work has been distributed cognition (DC) as a way of understanding human--tool collaboration. Elements of Hutchins, Norman and the other UCSD group members show up in applications of ideas such as precomputation and external memory. I have also looked at European DC researchers such as Fields, Wright, Harrison, Scaife, and Rogers. This work is unlike typical cognitive science degrees that strive to build a new theory and then seek validating data. There is plenty of potentially useful theory already. It isn't very easy to find and recognize, but it is there. My focus has been to carefully pick out ideas from existing theory and massage them into a form that can hopefully be applied by computing science researchers.
I have been influenced strongly by the cognitive dimensions work of Green and his collaborators, particularly with respect to the goal of broad brush theory and vocabulary building. The work has also carried on in lines similar to Carroll and Rosson (and collaborators) in their aim at making the psychological claims underlying tools more explicit.
I've found the theory-development route extremely hard but most delightful (which is probably why I've been able to stick with it). I find great satisfaction in the fact that my thesis work has woven in themes from software engineering, HCI, and cognitive science. In the future I hope to explore some of the lines of thought that my work opened up such as lightweight field observation techniques, instantiating some of my ideas in software engineering tools, and further transferring insights from theory to software engineering researchers and even practitioners.
Research Assistant, Dept. of Computing, The Open University, UK
I graduated from Bournemouth University in 1998 with a BSc (Hons) in Applied Psychology and Computing and I am currently studying for a post-graduate Diploma in Psychology. My research interests include how students learn to program, and how this knowledge can be applied to improve the teaching and learning of programming. I am also very interested in child psychology, and in terms of PPIG's interests, especially in how children learn to use computer software.
Currently I am working as a Research Assistant at the Open University. One of the projects I am involved in at the OU is known as AESOP. AESOP, An Electronic Student Observatory Project, is a collection of computer-based data collection tools for instruction and research in Computer Science education. I joined the AESOP project when it was in its pilot stages. Earlier this year we conducted a large-scale study collecting data from over 300 students (we are still analysing the data!).
At present we are focusing on 2 projects:
If anyone is interested in finding out more about these projects they can contact me at: email@example.com
My name is Orit Hazzan and I am a senior lecturer at the Technion - Israel Institute of Technology.
My work focuses on the human aspect of software engineering in general and on the communication within software-development teams in particular. This includes mental processes involved in developing software systems and social processes among developers of software systems.
This interest leads me recently to check the possibility of applying the Reflective Practitioner framework (Schön, 1983, 1987) to the art of programming. In short, the Reflective Practitioner perspective guides professional people (such as, architects, managers, musicians, and others) to rethink and examine their professional creation during (reflection-in-action) and after (reflection-on-action) they accomplish it. The working assumption is that such a reflection improves the performance within these professions. An analysis of the nature of the art of programming suggests the adoption of the Reflective Practitioner methodology to programming. I find this topic especially relevant in light of the last on-line discussion of PPIG discussion group.
I can be contacted at firstname.lastname@example.org
Schön, D. A. (1983). The Reflective Practitioner, BasicBooks.
Schön, D. (1987). Educating the Reflective Practitioner: Towards a New Design for Teaching and Learning in the Profession, San Francisco: Jossey-Bass.
Program auralisation aims to communicate information about program state, data, and behaviour using audio. The CAITLIN system was constructed to provide auralisations within a formal structured musical framework. Pilot studies showed that programmers could infer program structure from auralisations alone. A study was conducted using twenty-two novice programmers to assess a) whether novices could understand the musical auralisations and b) whether the musical experience and knowledge of subjects affected their performance. The results show that novices could interpret the auralisations (with accuracy varying across different levels of abstraction) and that musical knowledge had no significant effect on performance.
A second experiment was conducted with another twenty-two novice programmers to study the effects of musical program auralisation on debugging tasks. The experiment aimed to determine whether auralisations would lead to higher bug detection rates. The results indicate that, in certain circumstances, musical auralisations can be used to help locate bugs in programs and that musical skill does not affect the ability to make use of the auralisations. In addition, it the experiment showed that subjective workload increased when the musical auralisations were used.
Details (including downloadable conference papers and the full PhD thesis) can be found at www.cms.livjm.ac.uk/caitlin
My new address is:
College of Information Science and Technology
3141 Chestnut Street
Philadelphia, PA 19104 USA
voice: +1 215 895 2490
fax: + 215 895 2494