Editor: Chris Douce

Contents

Editorial

PPIG ‘04 Enda Dunican provides us with further information regarding this year’s workshop.

Book and Journal Reviews - Chris Douce reviews Secure Cording: Principles and Practices by Mark Graff and Kenneth van Wyk

Conferences, Workshops and Call for Papers

New Projects Andree Woodcock from the Design Institute, Coventry University, UK, introduces his new project.

Links beyond Derek Jones supplies us with an interesting and useful set of related links

Spotlight on PPIGers where you are and what you are doing.

Help Wanted Fellow PPIGers require your assistance

Cognitive Cultural Diversity and Software Design, a discussion paper by Allen Milewski and Richard Clayton

CamelCase remembers the contentious topic of identifiers, summarised by Chris Douce

PPIG mailing lists A reminder about the PPIG mailing lists

Editorial

Welcome to the Winter edition of the PPIG newsletter!

Many thanks to all contributors who helped to create this latest edition of the newsletter. I know there are many more of you out there waiting for the right moment to contribute! Remember, there is always a right moment.

This newsletter, like the workshop is a forum to share ideas. If you find something that may be of interest to us, please do tell. Similarly,opinion pieces are also greatly appreciated.

Perhaps there are some programming professionals out there who subscribe to the PPIG mailing lists. If so, we would especially like to hear from you, your problems, and your successes.

The most important section of this new newsletter describes the forthcoming workshop, to be held in Carlow, Ireland. Details regarding this workshop are provided by Enda Dunican, where you will find some information about Carlow and the surrounding areas.

As usual, you will find enclosed a book and journal review section. In this issue you will find a review of Secure Coding : Principles and Practices. Security isn’t something that appears very often at PPIG workshops, although it is a topic of considerable importance, especially in the light of recent news coverage.

Allen Milewski and Richard Clayton have contributed an interesting discussion paper, and Derek Jones provides us with a set of interesting (and topical) links.

Towards the end of this newsletter is a reminder about the two PPIG mailing lists – how to subscribe, how to unsubscribe, how to resubscribe and access the mailing list archives.

Hope you enjoy this winters newsletter, and I look forward to seeing you all in the Spring!

Chris Douce
Chrisd(at)fdbk.co.uk

PPIG ‘04 - 16th Annual PPIG Workshop

Enda Dunican from the Institute of Technology, Carlow, Ireland will be hosting the 16th Annual PPIG workshop between Monday 5th April 2004 and Wednesday 7th April.

A featured theme at PPIG 2004 will be research in the area of computer science education. The authors of selected papers submitted in this area will be invited to develop their papers for submission to a special issue of the Computer Science Education (CSE) journal to appear in 2005. Papers covering other topics of interest to the PPIG community (including work-in-progress papers) are also invited and welcomed.

Aims and Scope

The annual PPIG workshop is a forum in which researchers concerned with cognitive factors in software engineering can present and discuss recent results, findings and developments.

A feature of the PPIG workshops has been their openness to a wide spectrum of concerns related to programming and software engineering, from the design of programming languages to communication issues in software teams, and from computing education to high-performance professional practice. Similarly, PPIG entertains a broad spectrum of research approaches, from theoretical perspectives drawing on psychological theory to empirical perspectives grounded in real-world experience.

Despite its name, PPIG aims to bring together people working in a variety of disciplines and to break down cross-disciplinary barriers.

Doctoral/Postgraduate Event at PPIG-2004

During the morning of 5th April we will be holding a doctoral event for postgraduate students. The aim of this session is for postgraduates to present their research and exchange ideas with their fellow students as well as getting feedback from experienced research supervisors who will be attending the session. This session is free and open to all postgraduate students attending the event. Furthermore we are hoping to subsidise students who wish to attend this event. Details of the level of subsidy will follow later.

Registration

The deadline for registration will be 5th March.

Accommodation

Accommodation will be provided at the Dolmen Hotel, Kilkenny Road, Carlow. Delegates are asked to book their accommodation directly with the Dolmen Hotel by phone or via their website. The delegate room per night for the PPIG conference is 55 euro per night B&B; for a single room. If you have any other requirements or you would like alternative accommodation lists, please contact Enda.

Dolmen Hotel Website: www.dolmenhotel.ie
Phone: 00353 59 9142002
E-Mail: reservations(at)dolmenhotel.ie

Getting To Carlow

By Bus: From Dublin Airport get the 747 route buses to Bus Aras (Central Bus Station) in the city centre where you can get a bus (Bus Eireann Coach) directly to Carlow. To plan your journey look at www.buseireann.ie, then click on:

• Your journey : timetables-journey planner
• From : Dublin (Busaras)
• To : Carlow (IT)

By Train: From Dublin Airport get the 748 route buses to Heuston Station where you can get a train directly to Carlow. To plan your journey look at www.irishrail.ie, then click on:

• Your journey : timetables-journey planner
• From : Heuston
• To : Carlow

It can be sometimes just as easy to get a bus from Dublin Airport to the city centre and then a bus/taxi from the quays (crossing O’Connell Bridge coming from O’Connell St side) to Heuston station. Most of the buses to Heuston Rail Station leave from bus stops outside the Virgin Megastores store.

By Car: The AA and RAC websites provide excellent information on travelling to Carlow which basically involves travelling southbound to get onto the M9/M7 motorway which is the main Dublin Waterford route.

Getting to the Institute

The Institute of Technology is approx .5 km from town centre on the main Kilkenny Road. The main entrance is via a slip road on the left hand side just before Munnelly’s garage/filling station. When you arrive on the campus you should enter the Learning Resource Centre (LRC) which can be accessed via the door close to the ‘Portal of Light’, a piece of art consisting of two large granite stones with something resembling a light sabre penetrating them.

Additional Information

More information regarding the Carlow institute and the surrounding area can be found by visiting the following links:

• Institute of Technology, Carlow, Ireland

• About Carlow and surrounding area

Here’s to a successful workshop. Look forward to seeing you all in Carlow!

Book and Journal Reviews

by Chris Douce

Secure Coding : Principles and Practices
by Mark Graff and Kenneth van Wyk
O’Reilly, 2003
ISBN 0-596-00242-4

As soon as I connect to this website, my computer begins to reboot, a colleague said to me, frustrated.

Ten minutes later, I figured out what was going on, thanks partly due to other people arriving in the office, asking an identical question. The year just gone by was a particularly difficult year for systems administrators due to the prevalence of a number of rather malicious internet worms. Several weeks later, reflecting on these frustrations, I discovered a book that was described in interesting terms.

On the back cover, it was written that, ‘Secure Coding sheds light on the economic, psychological and practical reasons why security vulnerabilities are so ubiquitous today’. When received the book, I found a section entitled ‘psychological factors’. The section introduction is tantalisingly concluded with the sentence, ‘we’ve seen little in the way of careful thinking about the influence human psychology has on the frequency and nature of security vulnerabilities’. I tend to agree.

Chapters are divided up into parts of the ideal software development cycle. Following the introduction, it begins with architecture, goes on to design, operations and then automation and testing. Numerous case studies pepper these chapters, including a sprinkling of C code for those who are demanding the cryptic.

In the preface, it is stated that the book does not contain ‘cookbook examples’ of how to write code, instead exploring the issue of security at a higher level. Similarly, it does not cover details about particular platforms, analyses of exploit examples and issues surrounding the design of certain types of applications. Generality is considered to be key.

My favourite chapter is the chapter describing software architecture, specifically a ‘security architecture’. It provides a list of things to think about, and then explains each one of them in turn. Whilst I have problems understanding the nebulous use of the word architecture, it seems to fit here - asking you to think about how things should go before going ahead and building.

This slim volume is well referenced. It contains references to our firm favourites, such as Gerald Weinberg’s Psychology of Computer Programming, and that well respected favourite about mistakes, Human Error by James Reason. Another favourite that references many PPIG related papers, Code Complete by Steve McConnell, is also recommended reading.

Secure Coding reminds me of (and references) another related book that has been recently published, Writing Solid Code by Steve Maguire, published by Microsoft Press. This is another text that I hope to get around to reading, especially since this book is now considered to be ‘required reading’ on the Redmond campus.

Whilst the book’s title makes an explicit reference to coding, it goes beyond what is normally considered to be coding. Many responsibilities in information technology are divided into artificial roles, such as software engineering and system administration, often for very pragmatic reasons. The authors feel that those who consider themselves as ‘coders’ should also have an appreciation of some of the topics found within system administration.

Computer programming is not merely about the somewhat simple act of coding. Secure Coding reminds the professional developer about what can go wrong. It reminds the developer to consider the environment in which software executes. It reminds the developer that his or her software may run in an environment that should be considered as hostile.

In one part of the book, the lesson is clear. No matter how well your programming may withstand certain types of programming attacks, all your hard work may be in vain if your system runs on an operating system or network that has not been configured correctly. A programmer or developer needs to know a little about what the systems administrator does and how he or she does it, and conversely a system administrator needs to know what kind of security is likely to be asked for by a programmer.

The advice is clear. Consider risk. Consider how your system generates and reports errors, consider whether an audit trail facility is needed. Consider technical issues and ensure you keep up to date with new releases. Consider thinking like an alien to break through the comprehension paradigm that the software developer has constructed.

Interestingly, Graff and van Wyk’s book gives some attention to open source software, and describes a number of incredibly useful tools. If learning about these tools allows software developers and system administrators to effectively resolve a minor network vulnerability, this alone is likely to be worth the cover price.

The more one reads about computer security, the more one begins to feel afraid. We are in a world filled with software jails, buffer overflows, and at the mercy of third party libraries and operating systems comprising millions of lines of code. This distant fear may be similar to how one may feel whilst reading a book about real infectious agents.

Security is a topic that is only occasionally addressed by the psychology of programming community (from attending previous workshops). Security intersects many areas that we have an interest in, notably language design, software development methodology and models of program comprehension. Security is definitely something we need to think about.

Interest (and concerns) regarding software security will, in my view, continue to increase.

Have you read a book that you think that others may find interesting? If so, please do tell us about it. We’re crying out for some reviews of psychology books! Send all reviews and ideas to chrisd(at)fdbk.co.uk

Conferences, Workshops and Call for Papers

Diagrams ‘04

3rd International Conference on Theory and Application of Diagrams
March 22-24, 2004
Cambridge University, UK

‘Diagrams’ is an international and interdisciplinary conference series on the theory and application of diagrams from any field of enquiry.

From early history, diagrams have been pervasive in human communication. Recent advances in multimedia technology have introduced increasingly sophisticated visual representations into everyday life. We need to improve our understanding of the role of diagrams and sketches in communication, cognition, creative thought, and problem-solving.

These concerns have triggered a surge of interest in the study of diagrammatic notations, especially in academic disciplines dealing with cognition, computation and communication.

It is the only conference that provides a united forum for all areas that are concerned with the study of diagrams: architecture, artificial intelligence, cartography, cognitive science, computer science, education, graphic design, history of science, human-computer interaction, linguistics, philosophy and logic, and psychology, to name a few.

Topics of interest include but are not limited to:

• diagram understanding by humans or machines
• reasoning with diagrammatic representations
• diagram usage in scientific discovery
• history of diagrammatic languages and notations
• formalization of diagrammatic notations
• novel uses of diagrammatic notations
• design of diagrammatic notations
• interactive graphical communication
• psychological issues pertaining to perception, comprehension, and production of diagrams
• computational models of reasoning with and interpretation of diagrams
• role of diagrams in applied areas such as visualization
• spatial information and diagrams
• usability issues concerning diagrams
• design with diagrams

More information can be found by visiting the Diagrams'04 website.

EASE ‘04

8th Conference on Evaluation and Assessment in Software Engineering
May 24-25 2004

For 2004, EASE is being co-located with the 26th International Conference on Software Engineering (ICSE), Edinburgh, UK and the proceedings will be published by the IEEE Computer Society.

• ICSE 2004 website
• EASE 2004 website

EASE welcomes papers on all aspects of empirical assessment and evaluation in Software Engineering. For details of previous conferences and their published proceedings, please see our web site above. Some of the topics that have been addressed over the years, and which are still highly relevant, include:

• Justifying the use of empirical assessment and evaluation in an industrial environment
• Product and component evaluation
• Meta-analysis of software experiments
• Process and tool evaluation
• Evaluation strategies
• Experimental design
• Testing strategies
• Quality assessment
• Software experiments, case studies and observational studies
• Replications of previous experiments and empirical studies

We do of course continue to welcome both full and short (experience) papers that address all aspects of evaluation and assessment in Software Engineering, especially where the experiences relate to the problems that arise from the use of emerging technologies and practices and from new domains of application.

IWPC ‘04

International Workshop of Program Comprehension
June 24-26, 2004
University of Bari
Dipartimento di Informatica
Bari, Italy

Comprehending programs is one of the core software engineering activities. Program comprehension is needed for reuse, inspection, maintenance, reverse engineering, reengineering, migration, and extension of existing software systems.

This workshop will provide an opportunity for researchers and industry practitioners to present and discuss both the state-of-the art and the state-of-the-practice in the general area of program comprehension.

We invite technical papers, working sessions, and tool demos on, but not limited to, the following topics:

• Theories and models for software comprehension
• Program comprehension processes and strategies
• Experiments and case studies with a focus on program comprehension
• Tools facilitating individual and team understanding
• Reverse engineering and visualization of software artifacts for the purpose of program comprehension
• Formal and informal peer reviews for the purpose of sharing comprehension
• Comprehension during large scale maintenance, reengineering, and extensions of existing systems
• Program comprehension for the purpose of assuring and increasing software security
• Understanding network-centric systems
• Understanding object-oriented frameworks and component-based software
• Software comprehension for integration into product line systems
• Software comprehension for migration towards web services
• Software comprehension in the context of aspect-oriented programming

More information about the forthcoming IWPC workshop can be found on the IWPC website.

ICCM ‘04

Sixth International Conference of Cognitive Modeling

July 29 - August 1, 2004
Pittsburgh, USA.
(jointly between Carnegie Mellon University and the University of Pittsburgh)

ICCM brings researchers together who develop computational models that explain/predict cognitive data. The core theme of ICCM2004 is Integrating Computational Models: models that integrate diverse data; integration across modeling approaches; and integration of teaching and modeling.

ICCM2004 seeks to grow the discipline of computational cognitive modeling. Towards this end, it will provide

• A sophisticated modeling audience for cutting-edge researchers
• Critical information on the best computational modeling teaching
• Resources for teachers of the next generation of modelers
• A forum for integrating insights across alternative modeling approaches (including connectionism, symbolic modeling, dynamical systems, Bayesian modeling, and cognitive architectures) in both basic research and applied settings, across a wide variety of domains, ranging from low-level perception and attention to higher-level problem-solving and learning.
• A venue for planning the future growth of the discipline

More information is available through the conference website

Tel ‘04

Technology Enhanced Learning Workshop

22 August 2004, Toulouse, France

Technology Enhanced Learning (TeL) has provided tools and infrastructure to education and training disciplines for over a decade. Related issues are as various as pedagogical and evaluation theories, integrated learning environments, experiments, trials and results from R&TD; deployment.

Relying on recent experiences and promising results from R&TD; projects, in particular EU endorsed initiatives (e.g. IST Projects: Lab@Future, Laboratory of Tomorrow, Mobilearn), the workshop will give educational institutions, experts, practitioners and technologists an opportunity to share their experience and possibly come up with a consensus on open issues.

Tel'04 is a one day workshop co-located with the WCC'2004 conference.

It will take place among other WCC events in the Congress Center (downtown Toulouse). The program will include refereed papers and invited talks by distinguished researchers and practitioners.

The proceedings will be published by Kluwer, the official publisher of the IFIP conference. For more details and submission visit: Tel'04 workshop website

More information about the WCC (World Computer Congress) can be found on the WCC website.

ICSM ‘04

IEEE International Conference on Software Maintenance September 11th-17th, 2004. Chicago,Illinois, USA

The International Conference on Software Maintenance (ICSM) is the world’s major international conference for software and systems maintenance, evolution, and management. For the 20th ICSM 2004 we invite you to join us in exploring issues related to maintaining, modifying, enhancing, and testing operational systems and designing, building, testing, and evolving maintainable systems.

ICSM 2004 will address the major challenges confronting maintenance and evolution. We will concentrate on identifying new opportunities for collaboration between researchers and practitioners.

More information about ICSM'04 can be found on the ICSM'04 website.

HCC ‘04

IEEE Symposium on Visual Languages and Human-Centric Computing Rome, Italy, September 26-29, 2004

The IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC) celebrates its 20th anniversary in 2004. Predicated on the idea that visual representations can greatly benefit the task of computer programming, the conference has become the premier international forum on VL research. Originally named “Symposium on Visual Languages”, the conference has undergone several changes in response to the evolution of the field. Its present name, extended to Human-Centric Computing, reflects the expanded mission of the symposium:

• to support the design, formalization, implementation, and evaluation of computing languages that are easier to learn, easier to use, and easier to understand by a broader group of people

Topics include, but are not limited to:

• Empirical studies of Visual Programming Languages and Environments
• End-user and Domain-Specific Programming Languages
• Formal specification of Visual Languages and Environments
• Meta CASE Tools for Visual Language Processing
• Human-Centric Computing Languages and Environments
• Human-Centric Software Development
• Multimedia Authoring Languages
• Multi-Modal Interaction Environments
• Software Engineering for Visual Applications and Languages
• Software Visualization and Animation
• Usability Evaluation of Visual Programming Systems
• Visual/Multimedia Environments for Distance Education
• Visual Approaches to Software Comprehension and to Software Re-Engineering
• Visual Environments for Ubiquity Computing
• Visual Geographic Information Systems
• Visual Language Theory
• Visual Modeling Languages
• Visual Programming Languages
• Visual Query and Visual Presentation in Databases

More information about HCC'04 can be found on the HCC'04 website.

New Projects

Programmers as Reflective Practitioners

Andree Woodcock
The Design Institute, Coventry University

We have been awarded a small research grant to open up investigation of whether programmers are ‘reflective practitioners’. We are focussing on those programmers who could be described as ‘software authors’. Those who originate a software concept, and then design, code and test it, fit into this category. A good example being the shareware games author.

Many professions are regarded as producing reflective practitioners - e.g. architects, surgeons and educators. The essence of reflective practice is that the practitioner is able to apply a deeply embedded expertise to a novel set of circumstances, through the process of ‘reflection in action’.

We will be particularly looking at how integrated the process of programming is in the process of design.

If the thesis, that the programming process itself is deeply associated with the design process is true, then this has implications for the efficiency of designer/programmer teams in relation to the sole software author - something which we would seek to research in depth in the future.

Links Beyond

PPIG related web sites

by Derek Jones

I have collected together a rather idiosyncratic list of web sites that I think will appeal to PPIGers.

Where do we go for news?

CogNew, is a relatively new website that aims to provide news of the Cognitive Sciences.

Items are posted by readers, who can also post follow up discussion points (yes, you’ve got it, this is a slashdot, slashdot.org, for the cognitive sciences; it even uses the same page design).

InfoDesign is another news site, however it has more of a blog feel to it.

Getting more specific, the Mental Space Lab is new and looks promising.

Language is very important to programming and there are some interesting languages resources out there:

The Linguistics Links Database provides tasters and pointers on lots of topics.

Those of you who are fans of the Terminator films might like a dose of the real thing, visit OpenCyc, ok so it is purely a language tool, but it does offer a large ontology to play with.

Readers are likely to have heard of WordNet but there is also FrameNet, based on a different underlying theory.

Those of you wanting words, words, words can find them in the ARC nonword database and the list of words.

The Language Evolution Site is a great resource for papers on language evolution (if you email any of these researchers don’t forget to tell them they should also submit their papers to CiteSeer.

Nothing to do on a cold winters night? Why not take part in a psychology experiment or pehaps read a classic paper from the history of psychology.

Those wanting a more structured learning experience can check out the MIT open courseware project. Great things are expected of this project. However, it is new and still has a long way to go (but it is growing fast, so keep checking for updates).

Those wanting reference information on cognitive psychology (ok, so the book is a bit on the bulky side, but it is now out in paperback) can check out Cognet.

Spotlight on PPIGers

Des Traynor

My name is Des Traynor, I began a PhD (cryptically) entitled The Analysis and Synthesis of Student Profiling in Adaptive Learning Environments. My work primarily involves using solid software engineering techniques to incrementally build a cognitive model of learning to program.

The system will be created using empirical evidence gathered from first year programmers, and their mistakes. A detailed overview of how this will be attempted will be present (hopefully) at PPIG 04 in Carlow.

More information of my work is available at my website below.

Email: dtraynor(at)cs.may.ie

Website: http://www.cs.may.ie/~dtraynor

Andrew Ko

I’m a Ph. D. student under Brad Myers, at the Human-Computer Interaction Institute at Carnegie Mellon. I’ve been following up on John Pane’s work in the Natural Programming project, focusing more on how programming environments can be more helpful My project is called project Marmalade (Yes, its an acronym).

Much of my work has been driven by human factors research on the cognitive mechanisms of human error. I’ve done quite a few studies of the Alice programming system being developed here at CMU, in order to get a sense for the causes of software errors in the environment. I also recently submitted a journal paper on a framework and methodology for studying the causes of software errors in programming systems. The framework entails describing the causes of software errors in terms of chains of cognitive breakdowns, which consist of the type of cognitive failure, an action, the interface, and the programming information that was acted upon.

Using the framework, I’ve done a thorough analysis of the causes of software errors in Alice. Because Alice has a structured editing interface (though quite different from the structure editors of the past), syntax errors and type errors are entirely prevented. What is left is a cycle of debugging breakdowns, which lead to software errors, which lead to further debugging breakdowns.

My first attempt at preventing some of these errors was to design a debugging tool. The root cause of the debugging breakdowns was biased reviewing: when their program failed, programmers had a large space of hypotheses to consider about the cause of their program’s failure, but they only considered a few and tested them insufficiently. To prevent these false hypotheses, I designed a debugging tool called the Whyline.

The Whyline allows programmers to ask questions about their programs’ failure in terms “why did” and “why didn’t” questions, using a simple hierarchical menu. The menu contains the objects that have been changed or that have performed actions, as well as the objects that could have changed or performed actions in the code. The answers are given in terms of a precise dynamic slice on the runtime history, giving programmers only the runtime actions directly related to the program output (or lack thereof) in question.

I hypothesized that by allowing programmers to ask questions directly about a failure, they would only form hypotheses about the cause of failure at a surface level, and be less likely to go down unproductive debugging paths. In comparing programmers’ performance in a study with and without the Whyline, this hypothesis was largely confirmed. Programmers without the Whyline were forced to form hypotheses about runtime behavior at the granularity of their code, requiring them to make faulty assumptions about their program’s runtime behavior.

With the Whyline, their assumptions were either immediately addressed in the answer, or available in the answer after brief inspection. Overall, programmers spent an eighth of the time debugging and progressed 40% further through their task. For more details about the Whyline’s functionality and the rationale behind its design, consult our CHI 2004 paper on the Whyline.

We think the Whyline is a good example of how a principled analysis of the causes of software errors can lead to a more helpful programming environment. In addition to refining the Whyline, we’re also looking at issues of creating, modifying, and testing Boolean expressions, example code repositories and mechanisms for reuse, as well as novel ways of constructing code that are less structured than Alice but more than your typical text editor.

If you have any questions about our work, you can reach me at ajko(at)cmu.edu and Brad at bam+@cs.cmu.edu.

Help wanted

Maria Rosales-Sequeiros

I am a Marie Curie Research Fellow in the department of Anthropology at University of Kent. I am doing my PhD entitled the construction of personal identity of international programmers working in transnational corporations in the UK.

I would be grateful if programmers (or individuals in related positions) working in transnational corporations or in academia could contact me to carry out some e-mail interviews.

I would also appreciate if you could give me contact names of any acquaintances in this situation that you may have.

Thank you very much for your help in advance and look forward to hearing from you.

Kind regards,

Maria Rosales-Sequeiros Marie Curie Research Fellow
Department of Anthropology, University of Kent at Canterbury, Canterbury CT2 7NS
m.rosales-sequeiros(at)kent.ac.uk

PPIG meets XP

(that’s eXtreme Programming… or any agile methodology)…

IF you are interested in researching XP from a broadly PPIG perspective
OR if you are a practitioner in an XP organisation
OR if you are interested in introducing XP into your organisation
THEN why not get in touch?

We are conducting ethnographic studies in XP organisations in order to get a holistic view of XP as both a technical and social accomplishment. We also run practitioner workshops etc. in order to share experiences and get the views of practitioners concerning the strengths and challenges of applying XP and other agile methodologies in the real world.

We are members of the Centre for Empirical Studies of Software Development at the Open University, and, until we get our website up and running, can be reached via Judith Segal at j.a.segal(at)open.ac.uk

Help wanted is a new section in the PPIG newsletter. Are you working on a project that requires expertise in a particular area? Pehaps you are seeking subjects with a particular background or set of skills? Perhaps the newsletter may be able to help.

Please send submissions to the help wanted section any time to chrisd(at)fdbk.co.uk

Cognitive Cultural Diversity and Software Design

Allen E. Milewski & Richard Clayton
Monmouth University
West Long Branch, NJ.
amilewsk(at)monmouth.edu
rclayton(at)monmouth.edu

Cultural Differences and the Software Industry

Cultural differences are currently a topic of intense interest in the software industry [5]. It has been clear for some time that international considerations are of critical importance when designing software products for users (e.g. [1, 9, 11]). But recently, the ‘offshore development’ phenomenon has raised interest in the possible effects of cultural differences on how software is produced.

Recent reports have outlined the traditional literature on culture and technology and have related these differences to descriptions of how international software production might proceed, and prescriptions about how to make the collaboration on software a success (e.g. [14]). For instance, the classic work of both Hall [6] and Hofstede, [8] suggest a set of dimensions along which various cultures are observed to differ. Hofstede’s dimensions include: Power-distance, collectivism vs. individualism, femininity vs. masculinity, uncertainty avoidance, and long- vs. short-term orientation. The emphasis in most of this work has been on the social, emotional and organizational implications of differences. Several writers, for example, have argued that cultural differences along these kinds of dimensions can have strong effects on user-acceptance of software products [9] software team collaboration [11] and decision making processes [16].

Cognitive Cultural Differences

Social, emotional and organizational factors are critical elements for the success of the globally-evolving software industry. However, there are other factors that may be equally important, and these appear to have been overlooked so far in the discussion of international software development. Specifically, these factors have to do with cognition and problem solving **. Software development can be viewed as a complex problem solving task. If it were the case that some team members collaborating on software development embraced certain cognitive approaches because of their cultural background, while others were more comfortable with different techniques, one might expect significant collaboration difficulties. Indeed, these difficulties could be magnified if the team members were geographically separate- i.e. where a team member’s cognitive preferences are reinforced by his/her own cultural milieu.

Software Engineering embodies a collection of problem solving techniques that generally assist the development process. These include, for example, the pervasive strategy of breaking a complex problem into simpler, more-solvable parts. After each part is solved, they may be integrated back into a whole. Modularization is a version of this approach applied to software parts, traditionally with a premium on modules with high cohesion and low, well-ordered coupling. The notion of abstraction is another cognitive technique that simplifies problem solving at one logical level by hiding complexities at other levels. A final example, among many other techniques: progressive refinement is a technique to help manage top-down conceptualization of the software.

Are these cognitive techniques universally accepted or are some cultures more comfortable with other approaches? Our review of the literature on software engineering research shows little or no empirical evidence to answer this question. We are beginning a research program to explore aspects of the question, but results are not yet available.

While there is no data available that is specific to the software development environment, there is growing evidence for cultural differences in general cognition and problem-solving strategies. Most recently for example, Nisbett [12, 13] has reported marked differences between Westerners and East Asians in a wide variety of experimental tasks. It is proposed that these behavioral differences are the result of a deep and pervasive cultural difference in the assumptions held and approaches taken to problem solving.

Specifically, East Asians are thought to take a more ‘holistic’ approach than Westerners with an ‘orientation to the context or field as a whole, including attention to relationships between a focal object and the field’ [10]. In contrast, Westerners are thought to be more ‘analytic’ than East Asians, an approach ‘which relies on more abstract, symbolic representational systems, and whose computations are a reflection of rule structure’ [13].

Among others, the actual empirical results reported by Nisbett suggest that: (i) those from analytic cultures focus their descriptions of visual scenes on objects and their characteristics, while those from holistic cultures focus on the relationship between objects or their context (ii) those from analytic cultures show no deterioration in memory for objects when they are shown in different contexts (backgrounds) for training and testing. Subjects from holistic cultures do. (iii) analytic cultures attribute causality to elements of a problem rather than to element interactions or field forces, as do those from holistic cultures, and (iv) those from analytic cultures engage in stricter categorization of elements based on rules about attributes compared with those from holistic cultures.

The ‘Holism vs. Analytic’ distinction made by Nisbett is very similar to several other distinctions made about individual differences in cognitive style. For example, individual differences in perception can be understood, in part, by positing that some perceivers are ‘field-independent’ and focus on ‘parts’ while others are ‘field-dependent’ in that their perception of parts of figures are more influenced by their relationships to the ‘whole’[17]. Indeed, Nisbett reports concomitant cultural differences in tasks traditionally used to measure field-dependence/field-independence.

Yet another, similar distinction has been made in the educational literature. Differences in learning style have been characterized as either ‘holistic’ or ‘serial’ [15, 7]. Monaghan [10] has shown measurable differences between these groups in strategies taken to solve logic problem wherein the ‘holism’ students use more of a ’top-down’ problem solving strategy whereas the “serialism” students initially concentrate on instances and move toward more general problem solving principles (“bottom-up”). This latter “holism-serialism” distinction has not been used to look at cultural differences per se, but its similarity with the other distinctions suggests that cultural differences might be likely.

In summary, several lines of research converge on the possibility of individual and cultural differences in certain cognitive tendencies having to do with modularization of problems. It should be noted that the differences studied empirically center on differences between Westerners and East Asians; it is not clear what differences if any, exist on cognitive dimensions across other cultures.

It should also be noted that these research areas suggest differences in strategies, approaches and style, rather than in problem solving performance per se. It is clear that most complex, real-world problems, including software design can be solved with a variety of strategies.

Nonetheless, the potential impact of cognitive cultural differences on international collaboration over software projects cannot be overstated. If people working on the same problem have very different conceptualizations of its underlying structure, the chances of miscommunication and confusion could be great. Cultural differences in social practices and beliefs will certainly have important effects on the growing international collaboration in the software industry. However the impact of possible cognitive differences across cultures might be even more critical to that collaboration.

How Cognitive Cultural Differences May Influence Software Design

Might some of the documented cultural differences in cognitive approach and problem solving strategy be reflected in software design? Since there is little or no literature investigating cultural differences in software-specific cognition, it is only possible to pose questions at this point, but there are many interesting possibilities. For example:

1. Would a cultural difference be expected in software modularization? For example, would software engineers from analytic cultures be expected to create smaller, more numerous objects with more focused functionality, greater cohesion and less coupling? On the other hand, would designers from holistic cultures create larger, more multi-functional objects? The latter might be expected from someone who stresses relatively less differentiation of parts, and can still fall well within what are considered ‘good’ design practices.

   While modularization in general is an essential design principle, how much is optimal and how it is best achieved are complex questions. In practice, there are wide variations in coupling and cohesion measures, even amongst successful systems [2]. While there is a relationship between module size and faults, its details are still not clear: e.g. some argue that smaller modules are not the most fault-free [4], (but see [3]). Moreover, one might even argue that any relationships between design modularization and such things as faults, debugging and reuse may, themselves, be open to cultural differences.

2. Given that Software Engineering education has traditionally stressed smaller modules, one might not find significant cultural difference in straightforward modularization measures, but might still expect related differences in design style. For example, would a cultural difference be expected in control-flow, such that software engineers from analytic cultures might create designs where activities are “caused” by individual objects? Those from more holistic cultures, with less object-attributable cause-and-effect may tend to create more complicated causal logic that involves the interrelationship between objects.

   Similarly, would one expect cultural differences in data-availability method? Developers from analytic cultures, when creating object methods, might tend to provide information to those methods by passing it as parameters. This is compared with an approach that sets object attribute values and then uses the attribute within the method. An emphasis on separate parts of an object might favor parameter passing. Anecdotal evidence (A. Anwar, PPIG newsgroup, 1/04 and personal communication) suggests that there may, in fact, be observable cultural difference in parameter-passing tendencies.

3. Aside from differences in the final software design, might differences be found in the strategies used to produce and communicate them? For example, would software engineers from holistic cultures be expected to prefer top-down design strategies (e.g. progressive refinement) more than those from more analytic cultures? Would they be more able to flesh out high-level structure and relationships before delving into details? That is, would more of a “breadth-first” approach be preferred over “depth-first”?

   In terms of project process, would designers from more holistic cultures when collaborating with others, prefer receiving high-level requirements and generating their own specifics? More analytic designers, on the other hand, might be more comfortable taking specific, detailed requirements to incorporate into code.

   Would one expect cultural differences in design representation? For example, would software engineers from more analytic cultures prefer representing design patterns and other key design elements as part of UML diagrams more than those from holistic cultures. Field-independent engineers might be expected to be better at parsing embedded elements from a figure [17].

4. Finally, what kinds of educational effects might be expected on any software design tendencies influenced by culture? Nisbett’s studies [13] often find that subjects born of one culture but raised and educated in another show results midway between the two – suggesting training effects. Would the same sort of result hold true for any differences observed in software design?

This is a sampling of questions that can be asked about the effects on software design of cultural differences in cognition. The answers, of course, are speculation at this point, but worth pursuing. As the software industry becomes increasingly international, there is no question that excellent software resources exist across the globe. The issue is – how will these resources engage in the collaboration necessary for development of complex systems. Understanding cultural characteristics of cognition is essential to facilitate this collaboration.

References

[1] Aykin, N. and Milewski, A.E. Practical Issues and Guidelines for International Information Display, N. Aykin (Ed.), Usability and Internationalization Of Information Technology, LEA Corp., in press, 2004.

[2] Brito e Abreu, F., Goulão, M., Coupling and Cohesion as Modularization Drivers: Are We Being Over-Persuaded? IEEE: Fifth European Conference on Software Maintenance and Reengineering, 2001.

[3] K. El-Emam, S. Benlarbi, N. Goel, W. Melo, H. Lounis, and S. Rai, The Optimal Class Size for Object-Oriented Software: A Replicated Study, National Research Council of Canada, NRC/ERB 1074, 2000. http:/*eer.nj.nec.com/elemam00optimal.html

[4] Fenton N. and Neil, M., A Critique of Software Defect Prediction Models. IEEE Transactions on Software Engineering, 25(5):676-689, 1999.

[5] Gilbert, G. and Sood , R, Outsourcing’s offshore myth. CNET-News.com, December 15, 2003.
http://news.com.com/2010-1022-5121783.html

[6] Hall, Edward, The Hidden Dimension, Anchor Books, Doubleday, New York, 1990. (Reissue of 1965.)

[7] Helander, M. (Ed.) (1990) Handbook of Human Computer Interaction (2^nd edition). North Holland: Elsevier Science.

[8] Hofstede, G, Cultures and Organizations: Software of the Mind, McGraw-Hill, New York, 1997.

[9] Marcus, A. and Gould, E. Cultural Dimensions and Global Web Design: What? So What? Now What?, Aaron Marcus and Associates, White Paper.
http://www.amanda.com/resources/hfweb2000/AMA_CultDim.pdf.

[10] Monaghan, P., Holist and Serialist Strategies in Complex Reasoning Tasks: Cognitive Style and Strategy Change, Research Paper EUCCS-RP-1998-2, 1998.
http://www-users.york.ac.uk/~pjm21/publications.html.

[11] Nielsen, J. (Ed.) (1990), Designing User Interfaces for International Use (vol 13.) Advances in Human Factors/Ergonomics, Amsterdam, Elsevier Science.

[12] Nisbett, R.E. and Norenzayan, A. Cognition and Culture. To appear in D. L. Medin (Ed.). Stevens’ Handbook of Experimental Psychology, Third Edition, 2004.

[13] Nisbett, R.E. The Geography of Thought: How Asians and Westerners Think Differently…and Why. Free Press, 2003.

[14] Olson, J.S. and Olson, G.M. Culture Surprises in Remote Software Development Teams. ACM Queue, Vol. 1, no. 9. December-January, 2003-2004.
http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=05.

[15] Pask, G. (1988). Learning strategies, teaching strategies and conceptual or learning styles. In R.R. Schmeck (Ed.) Learning strategies and learning styles. New York, Plenum Press.

[16] Strohschneider, S. (2002). Cultural Factors in Complex Decision Making. In W. J. Lonner, D. L. Dinnel, S. A. Hayes, & D. N. Sattler (Eds.), OnLine Readings in Psychology and Culture, Western Washington University, Department of Psychology, Center for Cross-Cultural Research Web site: http://www.wwu.edu/~culture

[17] Witkin, H. A., & Berry, J. W. (1975). Psychological differentiation in cross cultural perspective. Journal of Cross Cultural Psychology, 6, 4-87.

_{** The distinction made here between cognitive factors and social/emotional/organizational influences, is admittedly arbitrary. The term ‘cognitive’ is meant here to mean those factors that influence perception, memory, attention and problem solving. Clearly, factors that influence how one thinks about a problem also affect how one interacts with others about it, and vice versa. Nonetheless, such a distinction is a useful shorthand that is traditionally made in experimental psychology.}

Identifying the right Identifier: CamelCase

Identifiers Rembered

By Chris Douce

This article is an attempt to highlight some of the research papers and books* during an interesting discussion that begun with the seemingly innocuous question of:

• Does anyone know of studies investigating the effect of casing on readability of program source code?

This original posting was later expanded, defining ‘harder to read’:

• The time taken to recognize whether or not a sequence of letters forms a legal word or not as opposed to the time and effort taken to read a whole sentence in upper case or mixed case.

The word readability was key. Readability can be read in different ways.

On one hand readability can be synonymous with that equally difficult term comprehensibility, or could be viewed as perceptibility, particularly in the cases of programming tools such as text editors and development environment. This raises interesting questions, especially since many of our software tools still continue to use the somewhat impoverished VT100 terminal environment.

The subject of readability (in perceptibility terms) is one that immediately begins to cross boundaries. One of the earliest posts introduced the topic of typography.

Is there something special about reading from the screen as opposed to reading from the page? HCI practitioners have been aware of such differences for considerable time. After all we usually read source directly from the screen before choosing to print, so we can annotate our printouts with notes and arrows on our pages (using our highly viscous pens and pencils).

One of the most appropriate references to be suggested was:

• Baecker, R.M. and A. Marcus (1990). Human Factors and Typography for More Readable Programs. Reading, MA, Addison-Wesley Publishing Co. (ACM Press)

A related paper is:

• Baecker, R. (1986). Design Principles for the Enhanced Presentation of Computer Program Source Text. Proceedings of CHI'86 Conference on Human Factors in Computing Systems. M. Mantei and P. Orbeton. Boston, ACM: 51-58

Other interesting papers include:

• Boyarski, D et. al. (1998) A Study of Fonts Designed for Screen Display Crafting Designs. Proceedings of ACM CHI 98 Conference on Human Factors in Computing Systems. p.87-94

• Dyson, M. C. and Haselgrove, M (2001) The Influence of Reading Speed and Line Length on the Effectiveness of Reading from Screen. International Journal of Human-Computer Studies v.54 n.4 p.585-612

Frank Wales unearthed an interesting link that explores the origins of a programming convention that we know as CamelCase:

• History, naming and origins of CamelCase

The immediate question being: is there some empirical research out there that tells us definitively that CamelCase is more useful than writingtextlikethis? One hypothesis being that it enhances readability due to the different shape of upper and lower case letters, and of course, allows us to more easily identify word boundaries.

• Arditi, A. and Cho, J. (2000). Letter case and text legibility. Supplement to Perception, 29, 45.

During this discussion, Derek Jones provides useful pointers to his commentary on the C 99 specification. Two links are particularly appropriate, providing us with a set of very interesting and appropriate references:

• Sentence 763 : Lexical Elements

In this section from his forthcoming book Derek describes what is called, ’early vision’, the phase of vision performed without apparent effort, and goes on to describe the rules of gestalt perception, edge detection as well as the processes of reading (eye fixation), and some interesting models of reading.

The second link explores the issue of identifiers and their processing in greater depth, providing a wealth of associated information that is again well referenced.

• Sentence 782 : Identifier Naming

Particularly relevant are the sections on identifier spelling, identifier spelling choices and further explorations relating to human language, memorability, confusability (my favourite) and usability.

Derek also provides us with a reference to research surrounding extreme case alternation (which could descend into altercation if used in anger):

• Herdman, C. M, Chernecki, D and Dennis, N (1999) Naming {cAsE} {aLtErNaTeD} words, Memory and Cognition, Vol. 27, No. 2, pp 254-266.

There is an interesting distinction that can be made here between intended and unrelated case changes. However, in terms of understanding the perceptual system that programmers constantly use, this research is particularly pertinent.

Programmers use secondary notion (such as indentation), and the the efficacy of particular typefaces to highlight program syntax (or role, or slice) could potentially support programming (and its related activities).

CamelCase, could be perceived to be a form of secondary notation for identifiers, where the case alteration distinguishes between useful identifier elements.

We are reminded of two other useful and related references:

• Green, T. R. G. (1990). Programming Languages as Information Structures. Psychology of Programming. J.-M. Hoc, T. R. G. Green, R. Samurçay and D. J. Gilmore. London, Academic Press: 118-137.

• Payne, S. J., M. E. Sime, et al. (1984). Perceptual Structure Cueing in a Simple Command Language. International Journal of Man-Machine Studies 21: 19-29.

An interesting point was raised when somebody asked: ‘surely there are more interesting/useful topics to perform research on!’. This is undeniably true. CamelCase, however (and identifier naming) is the stuff of programmer arguments, which indicates that programming style is a topic that will remain in fashion for some considerable time.

PPIG Mailing Lists

Membership to PPIG email lists is synonymous to being a member of PPIG (although you could be a member even if are not a member of either of the two lists). The mailing list (and, of course, the newsletter) is the primary way for members of the community to communicate.

There are two main lists:

• ppig-discuss Discussions regarding programming related issues, and questions relating to research can be posed here. This is usually a relatively low volume list (depending upon what is being discussed, of course!)

  You can subscribe to the discuss list by following this link:
  https://limitlessmail.net/mailman/listinfo/discuss

• ppig-announce This list provides information about relevant forthcoming conferences and workshops, including call for papers. It contains details about the forthcoming PPIG workshops, dates, times and calls for papers.

  You can subscribe to the announce list by following this link:
  https://limitlessmail.net/mailman/listinfo/announce

PPIG members usually subscribe to both lists. Announce is a low volume list. If you must only subscribe to one list, announce must be the one.

An archive of the PPIG discussion list is maintained. You can access it by visiting the mail archive website:

• PPIG Discuss Archive

Similar information about the mailing list can also be found on the PPIG website.

Acknowledgements

Many to Frank Wales and Paola Kathuria for the assistance they have given during the production of this newsletter.