Editor: Chris Douce
Contents:
PPIG 2005 Workshop Pablo Romero provides some details about the forthcoming workshop
Work in Progress Workshop Review Eileen Doyle provides a fine eye-witness report on the event that was the Unroll your ideas work-in-progress workshop
Book and Journal Reviews - Chris Douce reviews Code Complete by Steve McConnell
Conferences, Workshops and Call for Papers
Spotlight on PPIGers where you are and what you are doing
Curiosity Corner Chris Douce presents an ecclectic list of programming related trivia and links
Factors affecting use of constructs Derek Jones presents a short article about the use of programming constructs
Software Patents A number of links to language design and software patent issues
Editorial
Welcome to the Spring edition of the psychology of programming interest group newsletter.
This edition of the newsletter begins with a review of last years work-in-progress workshop held at Nottingham University. These additional events do occur from time to time. If you have an interest in developing a similar workshop, or developing a topic specific event please feel free to pose this as a suggestion to the discussion e-mail list.
As always, the newsletter includes the Spotlight column. This is where fellow PPIGers tell us about their projects, papers and generally how they are getting along. This issue is filled with a particularly interesting collection of submissions. If you have any questions (or suggestions), then please feel free to e-mail the contributors directly.
Please remember that the next PPIG event is almost upon us. As mentioned later, it will be hosted by the School of Informatics (formerly COGS) at University of Sussex, Brighton. If last years event is anything to go by - this one will be a cracker. Sussex University is relatively easy to get to both nationally and internationally, being well serviced by road, rail and air links. If the topics explored within this newsletter (and the earlier workshops) is your cup of tea, you have no excuse. Pablo expects to see you there.
This issue contains a book review, one which may be recognised by many. We’re crying out for reviews and references to psychology journals and texts. We know there are some psychologists who subscribe to PPIG - the engineers are waiting to hear from you.
I hope you find this issue interesting and informative. Again, please don’t wait until the call for newsletter articles appears - please feel free to send submissions at any time.
Chris Douce Chrisd(at)fdbk.co.uk
PPIG 2005
Psychology of Programming Interest Group (PPIG) 2005
28 June-1 July 2005, Department of Informatics, Brighton, UK.
The annual PPIG workshop is a forum in which researchers concerned with psychological aspects of software development can present and discuss recent results, findings and developments.
Despite its name PPIG entertains a broad spectrum of research approaches, from theoretical perspectives drawing on psychological theory to empirical perspectives grounded in real-world experience, and is equally concerned with all aspects of 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.
During 28th and the morning of 29th June, a doctoral event for postgraduate students will be hosted. 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 year’s PPIG doctoral event will be organised in partnership with The University of Sussex’s Human Centred Technology Postgraduate Workshop. Details of this workshop can be found at:
Human Centred Technology Postgraduate Workshop
Information regarding the University of Sussex and the department of Informatics which is hosting PPIG can be found from following websites:
General information about the workshop, including accommodation and registration, can be found at the workshop website â check regularly for updates!
More details about the city of Brighton and its attractions can be found through the following illuminating website:
If you have any questions regarding the event, please don’t hesitate to contact the local organiser Pablo Romero : pablor(at)sussex.ac.uk
Work in Progress PPIG Workshop
Unroll Your Ideas: a work-in-progress meeting of the Psychology of Programming Interest Group
December 15-16 2004
University of Nottingham, UK
Review by Eileen Doyle
The first workshop for Unroll Your Ideas took place in the University of Nottingham. The workshop comprised four sessions, during which fifteen research ideas were presented, covering areas such as extreme programming, empirical modelling and teaching and learning computer science.
The workshop commenced with a keynote speech on teaching debugging by Eric Roberts. Eric supplied us with interesting references like Robert Pirsig’s Zen and the art of motorcycle maintenance to emphasise the psychological and cognitive aspects of debugging.
The first session started with Sallyann Byant who presented her investigation on software quality through observing programmers working in industry to identify their qualities for pair programming.
The next presenter was Clive Rosen who provided us with the best analogy of the workshop. While presenting his research on exploring a theoretical basis for the software engineering paradigm Clive compared the purchasers of software to those who purchase dog food (Do either use the product they purchase?).
The session concluded with Paul Adams who gave us a flavour of his work on the role of ego in libre pair programming.
The first day finished with Luke Church’s discussion on the possibility of using continuous gesture system and language model to provide an alternative entry mechanism while highlighting some of the questions raised by the design of this system.
The second day began with the session on empirical modelling; first to present was Charlie Care who aims to conduct a study which restores the analogue quality to modern programming based on computer based artefacts which can be used to enable the understanding of physical artefacts. This was demonstrated through a computer based model of a planimeter (a device used to calculate areas). Karl King intends to develop an artefact to explore to what extent tools support modelling in the stream-of-thought.
The next session opened with Marizieh Ahmadzadeh. The goal of her research is to refine teaching methods based on the observation of students’ mistakes (complier and logical errors). This is achieved through examining pattern of compiler and debugging logical errors in the practical exercises of novice students.
Ioanna Stamouli explored the main conceptions of undergraduate students have of the fundamental principles of object-oriented programming using the phenomenographic approach. Orna Muller presented her work on pattern-oriented instruction on algorithmic problem solving.
The ExploreCSEd team presented their project which is to investigate the cognitive skills involved in learning to program and the major difficulties that students face when trying to learn this subject, irrespective of the programming language. To realise the goal of this project the team seek to recruit participants who are willing to apply the developed tool in their home institutions.
For more information on this project or to participate please visit:
Papers addressing extreme programming, empirical modelling, teaching and learning computer science were featured. The workshop concluded with an excellent summary of these papers and the discussion sessions by Marian Petre.
Towards the end of the workshop I gathered informal feedback from some of the participants on the features of the workshop that they found the most beneficial. This is what they thought:
- Speeches from the invited speakers (Eric and Marian) were very inspirational.
- Discussion on current issues allowed for reflection on problem that participants encounter in their discipline.
- Meeting postgraduates for a similar research setting to swap stories and establish communication links.
- Meeting experts in the field.
- Gaining constructive feedback on each individual’s research.
Highlighting the issues involved in conducting research to supplement the advice from supervisors.
I would like to finish on a personal note, this was my first PPIG event and I found it an excellent source of feedback for my research and great fun. Also it provided a great opportunity to meet other doctoral students.
One item that I would like to highlight for future attendees is to think about what you want to get from the participants and include it as part of your presentation, this was a great help to me.
Finally I would like to thank Marjahan and her team for organising a successful event and I hope to see more of this kind of activity in the future.
Book and Journal Reviews
by Chris Douce
Code Complete : A practical handbook of software construction (Second Edition)
by Steve McConnell
Microsoft Press, 2004
ISBN 0-7356-1967-0
Not long after discovering Software Psychology by Ben Shneiderman in the university library, I remember being excited when I stumbled over what almost seemed to be a code oriented contemporary equivalent in a local bookshop: Code Complete.
Leafing through the first edition I remember being particularly struck by the ‘hard data’ icons and began to recognise a number of the empirically-oriented papers. At the time of finding the first edition I had an emerging interest in some of the more contentious issues in software development, namely identifier naming, commenting and layout. These are some of the issues that Code Complete aims to address, presenting empirical evidence alongside words of practical advice.
The subtitle of Code Complete describes it as a practical handbook to software construction. Divided into a number of parts, the first sets the ‘construction’ scene. Here McConnell scopes Code Complete. The book is targeted firmly in the arena of the practising programmer whilst giving important nods to the surrounding issues of problem definition, maintenance, approaches for system architecture and testing.
After laying the foundation, design approaches and the programming process is explored. This is then followed by sections exploring the use of data (variables), control flow (statements) and what could be considered as good practice.
Reading a book like Code Complete naturally makes me question my own practices (which is, of course, one of its main intentions). When reading the section on ‘developer testing’ digesting references to research regarding error rates I couldn’t help but think about whether my own practices could be improved.
Programmer performance is an issue that is explored a number of times. In one section, a twenty to one difference in debugging performance between experienced and inexperienced programmers was cited. Another section describes a ten to one difference in the amount of time it takes to construct (or write) a program.
The penultimate chapter, personal character, begins to explain why. Efficient developers and programmers, McConnell argues, do not have to be super intelligent but they should have an appreciation of how limited one’s one mental capacity is. In essence, a programmer needs metacognitive awareness which is an interesting programming education topic. Education and programmer self-education (whether it being reading of books or developing of throw away programs) is a topic which is also explored within Code Complete
The heart of Code Complete is about getting things done the right way, specifically constructing code that does what is intended in a way which doesn’t trip other engineers (or artisans) up. This is achieved, it is suggested, by reducing the complexity that a programmer has to deal with from a number of different perspectives. The Code section of Code Complete is all about suggesting efficient ways to formulate information that both human and machine can parse.
A number of complexity management heuristics are: When writing comments, describe ‘why’ a program does something rather than ‘how’ it does it since this should be self-evident from the code, and keep them to the point. When using variables don’t use crazy names and always try to keep the declaration as close to where it is used. Finally, if in doubt (or think that anyone else may ever be in doubt), parenthesize.
Code Complete combines together two sub-disciplines within the psychology of programming: the psychology of programming using programming languages, and the psychology of software engineering. Here’s a quote I like: ‘The whole job of programming is building air castles - it’s one of the most purely mental activities you can do. Consequently, when software engineers study the essential properties of their tools and raw materials, they find that they’re studying people: intellect, character, and other attributes that are less tangible than wood, concrete and steel’.
Those familiar with the first edition of the book will be familiar with the format and contents of this new edition. Much has changed, however, as is evident from the table of contents. There are new sections. Others have moved around or have been combined. This movement is particularly noticible in the first chapters - the introduction into the code aspect of construction is more gradual and is more rounded as a result.
In line with the changes in programming languages, the examples have changed too. Samples written in Pasal, the language of choice for the educator during the eighties to nineties has been replaced by samples in Java. Programs written in C have sensibly migrated into C++.
As languages have changed, more research exploring the human (and engineering) aspects of programming has been carried out. The ‘hard data’ side bars have been updated with new references and whole sets of new papers described, suggesting reading that will keep some of us going for quite some time.
Since the publication of the first edition the perception of appropriate working practices has also changed. There are now discussions that examine the merits of current engineering approaches such as pair programming. This is presented alongside discussions regarding software quality and the advantages that rigorous code reviews may bring.
I like Code Complete - it is easy to read and very well referenced. It is also code focussed which, for some, will hit the spot. If, however, you want a book regarding the state of the art design practices or information about how to manage a programming team (or even your manager) you can’t go far wrong by checking out what Code Complete references. And while you’re in the neighbourhood, reading a couple of chapters might do you some good too.
It was also interesting to learn that Robert Pirsig once worked as a software technical writer. Also, if you want to know what Homer Simpson has to do with software engineering I urge you to visit your local library to borrow Code Complete. There’s a treat awaiting you.
The companion website to the book can be found at:
Do you know of a journal that may be of interest to fellow PPIG members? If so, please tell us about it. Interested in writing a review, or perhaps you are an editor and would like to introduce your journal to us? Please feel free to send a message to chrisd(at)fdbk.co.uk
Conferences, Workshops and Call for Papers
SPA2005 - Software Practice Advancement
April 10-13, 2005
The Robinson Centre, Bedfordshire, England
SPA2005 explores the following issues:
Technology: Technology is the bottom line in software. Topics include:
- Enterprise Development Platforms (J2EE, .Net)
- Internet technology, eCommerce and Web Services
- Languages (Java, C#, Python, Perl, Smalltalk)
- Distributed, component-based or service-based development
- Pervasive or embedded systems
People: Software is an intensely human activity and understanding how to organise and support people is a key challenge in software development. The conference will cover such topics as:
- Dynamics of software development
- Education and training
- Communication, motivation and reflection
- Problem solving and thinking models
- Organisational structures
Practice: Sharing knowledge and experience of successes and challenges is critical in the face of rapidly increasing complexity. Topics include:
- Patterns and pattern languages
- Knowledge management and capitalisation
- Comparative experience (what we have learned or can learn from other disciplines)
- Experience reports that highlight lessons learned
Process: Understanding the ‘how’ of software development and delivery is a central issue. Sessions might examine:
- Software or system architecture
- Requirements capture management and evaluation
- Metrics and estimation
- Modelling techniques
- Agile verses plan-driven lifecycles
- Balancing stakeholders’ needs
More information can be found at: SPA2005
Editors note: Session 42 looks particularly appealing
ACCU 2005
April 20-23, 2005
Oxford, UK
The ACCU Conference 2005 will bring software professionals the chance to hear about the latest ideas in software development.
The ACCU Spring Conference 2005 boasts an impressive technical programme with an emphasis on C++, Java and Python, with tutorials, workshops and discussions on eXtreme Programming, Patterns and embedded software. This year’s event features keynote talks by Bjarne Stroustrup, Jim Coplien, Ross Anderson and Kevlin Henney.
The programme has been designed to facilitate dialogue between developers, analysts, planners and managers. It addresses a wide range of subjects including the development process, design, analysis, and patterns as well as softer aspects such as team building, communication and leadership.
The lineup of speakers includes many well known industry figures, writers and practicing developers from the front line of software development.
12th Annual ACT-R Workshop
July 15-17, 2005
Trieste, Italy
ACT-R is a cognitive theory and simulation system for developing cognitive models for tasks that vary from simple reaction time to air traffic control.
The foundations of the ACT-R theory were detailed in the book The Atomic Components of Thought by John R. Anderson and Christian Lebiere, published in 1998 by Lawrence Erlbaum Associates.
Recent advances in the theory are detailed in several publications accessible at the url:
Each year, a three-day workshop is held to enable new and current users to exchange research results and ideas. The 12th Annual ACT-R Workshop will be in Trieste, Italy, on July 15-17, 2005 (just a few days before CogSci2005 in Stresa). During the workshop participants will illustrate their ACT-R research in 20 minutes presentation. Nick Chater (University of Warwick, UK) will be the workshop invited speaker.
More information can be found on the CogSci webiste:
27th annual meeting of the Cognitive Science Society (CogSci 2005)
HCI 2005
September 5-9, 2005
Napier University, Edinburgh, UK
HCI2005 is the 19th Annual Conference of the British HCI Group, a specialist group of the British Computer Society. Established in 1985, the conference has become the premier annual conference on Human-Computer Interaction in Europe. Attracting hundreds of researchers and practitioners from over twenty countries, its published proceedings (The People & Computers series) form an important part of the archive of HCI research.
In returning to Scotland in 2005 we particularly welcome the involvement of the Nordic community, both as organisers and presenters, and the conference flavour hopes to reflect the shared culture of nations bordering the North Sea and Baltic Sea.
The HCI conference has always addressed the needs of practitioners and researchers through a balance of conference activities. Each annual conference has a theme, but submissions on any HCI topic are always welcome.
Spotlight on PPIGers
Would you like to tell other PPIGers how you are and what you are doing through the newsletter? If so, please e-mail chrisd(at)fdbk.co.uk.
Sebastian Jekutsch
Sebastian’s research topic is entitled: Investigating programmer’s work to analyse defect insertions
With more extensible and more integrated programming environments at hand (e.g. [1]), and with growing insights into the dynamics of programming (e.g. [2], [3]) we started a project with the aim of automatically observing a programmer’s behaviour to predict defective code.
We assume that code defects are actively being built into software, because
- programmers - being humans - make errors
- making errors is not bad luck and therefore defects do not occur by chance and should not be treated by statistical means only
- defect prevention, i.e. prevention of making errors, is to a great extent a task of process observation and process adjustment.
We are focussing on what we call ’the micro-process of software development’. The micro-process is a stream of events occurring during development. Restricted to coding, this can be:
- extending code parts bottom-up
- browsing through code
- executing the program
- pausing for a while, etc.
In our study, we try to find significant correlations between some suspect coding behaviour (i.e. episodes of coding events at some code location) and later changes of this code, especially defect removals. We want to assist the programmer in answering questions like:
- What happened when I constructed this defective code?
- Which part of the code was constructed in the same manner?
- What seems to be my typical coding behaviour which results in coding defects?
Typical defect-prone micro-process patterns or episodes are:
- being interrupted and not resuming work where left off
- changing a small part of code very often
- not changing copied code fragments consistently, etc.
We will build our hypotheses on the observations published in the area of programming psychology, especially in programming seen as a problem solving activity and its known anomalies.
The optimal result of our research would be a tool which automatically issues a warning to the programmer as soon as suspect episodes are detected (via just-in-time analysis of the event stream). It remains to be seen whether this will result in some really useful hints or if the amount of false positives will render it useless. A captured and stored micro-process may alternatively be replayed as a means for the programmer to learn from mistakes.
The research steps are:
- collecting micro-process events (using a general framework [4])
- doing qualitative research to build hypotheses on defect-prone coding episodes
- trying to automatically detect those episodes
- doing experiments on the applicability of the recognizer and its predictive power concerning later defect removals
Other work in our working group [5] includes studies to examine API documentation usage and programming task influence of the usefulness of pair programming.
We would be very pleased to get any comment about known issues in human error in programming and its observable characteristics, about related projects and research questions, and about any experimental work already done for programmer’s coding behaviour, especially concerning coding defects.
[2] Willemien Visser, Jean-Michel Hoc. Expert Software Design Strategies. In: J.-M. Hoc, T.R.G. Green, R. Samurcay, D.J. Gilmore: Psychology of Programming, Academic Press 1990
[3] Simon P. Davis. Models and theories of programming strategy. Int. Journal Man-Machine Studies (1993) 39, 237-267
[4] http://csdl.ics.hawaii.edu/Tools/Hackystat/
[5] http://www.inf.fu-berlin.de/inst/ag-se/
Sebastian is a student at the Freie Universitat Berlin, Working Group on Software Engineering. You can contact Sebastian by e-mailing him using jekutsch (at) inf.fu-berlin.de.
Derek Jones
Derek has recently carried out a series of experiments that explore memory for short sequences of assignment statements.
The papers describing these experiments and their associated results can be found by following the below link:
Derek Jones is an ex-compiler writer who is trying to find something else to do.
Gerold Keefer
Gerold has recently published an article entitled Pair Programming : An Alternative to Reviews and Inspections.
This article takes an in-depth look at the empirical research results available on pair programming and inspections. It reveals that a prominent experiment in that area has a range of flaws that were detected by several researchers and practioners independently.
A copy of this paper can be found by following the below link:
Pair Programming : An Alternative to Reviews and Inspections
Michael P. O’Brien
Michael is a student at the Department of Computer Science and Information Systems at the University of Limerick, Ireland. He introduces his research topic: Characterizing Information Behaviour During Software Maintenance - An Empirical Approach. A paper describing Micheals’ earlier work has been recently published in the Journal of Software Maintenance and Evolution.
Much research has been carried out to date suggests that both comprehension and information seeking are major parts of software maintenance. However, it remains the view of many computer scientists that the standard of empirical software engineering in this area leaves scope for improvement.
There is, however, an increasing awareness in the software engineering community that empirical studies are a vital aspect in the process of improving methods and tools, for software development and maintenance.
It is interesting that up to 70% of expenditure on software systems, occurs after delivery - during maintenance and evolution. Of this 70%, researchers report that over half the effort expended is due to ‘understanding’ the system. Unfortunately, as a research community, we can provide little guidance to professional software engineers as they carry out their maintenance/evolution tasks.
Preliminary studies already carried out as part of this research, suggest that understanding large commercial software systems seems not guided by the cliched comprehension strategies, said to be employed during maintenance activities. Instead, the process is driven by an information requirement.
Essentially this research aims to analyse high ecologically valid talk-aloud data from several empirical studies of programmers carrying out ‘real’ maintenance tasks in situ. The data will be examined (in a data-centric grounded theory fashion) from several perspectives (already hypothesised upon / studied in the community) in the information-seeking paradigm - and will aim to answer questions; for example, at a low level, how do programmers use lexical meaning in the sessions?
At a higher level, what do they reason about in terms of structure (architectural, file, etc) or do they neglect it altogether. The data will be further analysed to identify the information sources programmers use during software maintenance along with the interleaving of these information sources.
Limited research has been carried out (mainly by the use of questionnaires), as to the information sources programmers rely on - however, to date, this research has not been specifically empirically validated in-situ.
Olga Smyslova
Alexander E. Voiskounsky and Olga V. Smyslova, M.I.N.D. Lab, Moscow State University, Russia, have been working on a study of computer hackers’ motivation for a few years. We developed a model of hackers’ motivational development, based on the flow experience paradigm. Hackers seem to have a strong intrinsic (i.e. with no external rewards, such as money or peer-recognition) motivation for their preferred activity.
A well-developed theory of flow experience, introduced by M. Csikszentmihalyi within the school of positive psychology, is intimately related to intrinsic motivation. As a practical tool, the flow experience is being intensely measured, taken various types of human-computer interaction.
Taken as granted that hackers experience flow, it was hypothesized that flow increases with the increase of hackers’ competence in the IT use. Self-selected subjects were recruited on specialized web sources; 457 hackers filled out a web questionnaire. Competence in the IT use, specific flow experience and demographic data were questioned.
An on-line research was administered within the Russian-speaking community (though one third of subjects are non-residents of Russian Federation). Two differing strategies of task choice were self-reported by subjects: a step-by-step increase of the difficulty of choices leads to a match of challenges and skills (and to preserving the flow experience); putting choices irrespective of the likelihood of solution leads to a flow crisis.
The findings gave productive hints on processes of hackers’ motivational development. The flow-based model of computer hackers’ motivation was developed. It combines both empirically confirmed and theoretically possible ways of hackers’ ‘professional’ growth.
The results of the study can be found in an article in Cyber-Psychology and Behavior ( Flow-Based Model of Computer Hackers’ Motivation. Alexander E. Voiskounsky, Olga V. Smyslova. CyberPsychology & Behavior. Volume 6, Page 171-180, April 2003). You can reach authors at vae-msu (at) mail.ru (Alexander Voiskounsky) or korobka (at) mail.ru (Olga Smyslova) to get a copy of the paper.
Future plans include cross-cultural study of software engineers in Russia, States and, probably, other cultures; study of the ethics in the software development. Other scientific interests of the Lab members include: Usability, Accessibility, Virtual Environments, Flow Experience of MUD-players, Online Communities.
Olga is planning a study of programming languages influence on thinking, comparing Object-Oriented Programming, Functional programming, and Procedural Programming.
If you have any suggestions or thoughts, or literature on the topic, please, share!
Mads Søgaard
I have just finished a report called Object Orientation Redefined: From abstract to direct objects and toward a more understandable approach to understanding.
The report investigates the connection between object-oriented formalisationand human thought processes. The report redefines/rethinks Object Orientation by problematising the distinction between Model (underlyingmeaning) and Interface, first from a philosophical and epistemological perspective and thereupon from a more practically oriented HCI, Computer Science, and Interface Design perspective.
In broad terms, the report orients Object Orientation in the direction of HCI and Interaction Design and conversely explains why Object Orientation may be regarded as a part of the field of HCI.
I will be most grateful for every remark, as well as advice on where to publish key points of the report. Since the report redefines objectorientation as a ‘cross section’ of the areas/theories/subject matters/etc that I introduce, I have trouble finding the right ‘disciplinary pigeonhole’for my work.
The report is available here: Object Orientation Redefined
Please feel free to e-mail Mads using mads (at) acm.org
Curiosity Corner
by Chris Douce
The following essays by Jack W. Reeves offer three perspectives on the notion that that programming is fundamentally a design activity and that the only final and true representation of the design is the source code itself:
Programming as a design activity
This sentiment reminds me of something that Mark Weiser of program slicing fame once wrote: that source code should be considered first, foremost and always (I may be paraphrasing) since this is what is really executed on a system. (You sometimes can’t trust the comments)
Within vehicle manufacturing, there was once the phenomenon of the ‘friday afternoon’ car - one which was built whilst the engineers attention was elsewhere, usually about what to do on a Friday night. Thankfully the ‘friday afternoon’ phenomena has just about disappeared in motor manufacturing.
I couldn’t help remembering this friday phenomena when a colleague told me about this website:
The following code (apparently) checks to see if a number is negative:
If (Mid(CStr(cppObject.GetValue()), 1, 1) = "-") Then ...
I think this submission must be a hoax. Even if it is, there is seriousness that can be found in this site: I urge all practiving software developers to review the code found here - it is a fantastic museum of the pathological and a shrine to the Friday Afternoon Function. (So far I haven’t seen any of my source code submitted - give it time…)
Most of the samples are likely to be viewed out of context (although I have to admit generating HTML tags from an SQL stored procedure is asking for trouble!)
Little is known about the history of the code presented. True, these fragments may represent extreme illustrations of conceptual entropy (due to continual of gradual maintenance until the boundaries between files, functions and packages dissolve) but may also represent true pathogens, complicating future maintenance, making problem solving and corrections harder to action.
Sometimes it may be difficult to see which is which until we begin to explore the ecology of the environment where software exists and begin prising apart associations using the tools that we have at our disposal.
This site raises some rather interesting questions about software aesthetics. There is little doubt that some of the samples are considered to be horrors, but what criteria do we apply to make such a judgement?
It can be said that coding horrors can have a number of dimensions - maintainability and efficiency for example. The importance between these dimensions may change, of course, according to application area.
McConnell uses an interesting quote by Plauger in Code Complete : ‘one symptom that you have bogged down in complexity overload is when you find yourself doggedly applying a method that is clearly irrelevant, at least to any outside observer.’
This reminds me of another annual event that has been going only slightly longer than PPIG has:
Eighteenth International Obfuscated C Code Contest
I recommend that you have a glance over the goals of the competition. Some of them are particularly noble.
A posting on Slashdot recently announced that an essay by Gerald Weinberg entitled ‘Personal Chemistry and the Healthy Body’ was recently republished in the Developer Dot Star magazine. This Slashdot submission was contextualised by the the ‘programmer abuse’ website:
This lies in a genre of sites similar to the dailywtf site. Although many of the comments may immediately come across as general gripes and whinges (like we all like to do from time to time, especially on a cold winters morning), some of this miserable bunch of whingers may indeed have something very insightful to say about the disasters that they work on.
Personal Chemistry and the Healthy Body : Gerold Weinberg
I conclude this section of Curiosity Corner with a link to a web-log. This web-log includes a familiar image to those who may be familiar with the reviewed text:
I don’t normally read web-logs but this one does look quite good fun.
A faculty member of a university in which I was recently working distributed the following link. (Please excuse this fine example of viral advertising. In the current context it’s too good to miss.) Apparently no cats were harmed during the making of the ad and as far as I know the cats chose to herd themselves at a time of their own choosing, totally oblivious to the directors deadlines:
On a more serious note, London Metropolitan University has developed a number of reusable learning objects that help to teach some of the principles of programming. More details of this work can be found at the project website:
Learning to program learning objects
The sample objects accessible from this website will be of interest to those researchers (and engineers) who construct (and evaluating) algorithm animation systems for use within both education and industrial applications. (I particularly recommend that you have a look at the while loop object).
The London Metropolitan Learning Technology Research Institute website can be found here:
London Metropolitan Learning Technology Research Institute
Continuing a didactic theme, one of the tasks that computer science (or should it now be called informatics?) lecturers have to do is evaluate student’s programming assignments. In the UK where student numbers in higher education have been increasing for a number of years, the problem of assessment can become seriously non-trivial.
Recalling that one of the attributes of a good programmer or software engineer is laziness (see The Pragmatic Programmer and, of course Code Complete), help is at hand in the form of three student programming assignment assessment systems. Three of which are detailed below:
ASAP : Automated Assessment of Programming (Kingston University)
BOSS : Bob’s Own Submission System (Warwick University)
CourseMarker (Nottingham University)
In developing these automated systems the engineers have to consider how lecturers assess the work of others. In programming systems, the simplest check is to ensure whether a system operates as described with a potentially linguistically ambiguous requirement specification. Secondly, does the submitted software design resemble in any way an ideal solution? Finally, one may wish to consider programmatic efficiency in terms of memory usage or processor time. (Remember, there is more than one way to skin a cat).
The programming assessments that are given to students are unlikely to be ‘wicked’ problems. Returning to Code Complete again these are problems which can be only clearly defined by beginning to solve it either in whole or in part. The terms of programming assignments are not usually changed before they are due to be handed in (although I have heard this approach described at an earlier PPIG meeting by one CS educator).
There are some particularly ‘wicked’ problems out there, and some of these are often debated by the British Computer Society. Some of these debates may be of particular interest to PPIG readers:
BCS Thought Leadership Debates
Not so long ago I recently discovered another book that may to be of interest to PPIGers: Code Reading - The Open Source Perspective. Whilst I haven’t had time to read it myself here’s a link to a review of the book from someone who has:
Book Review: Code Reading - The Open Source Perspective
Continuing this final section where we read about what others have read (a meta-review?) Derek Jones also directs us to a relatively new site which allows you to find interesting papers which have been discovered by like minded people.
These curiosities complete with a topic which appears to be of perenial fascination: a family tree of programming languages. Here are two interesting equivalents - one for the horizontally challenged, the other for the vertically challenged:
Factors Affecting the use of Language Constructs
by Derek Jones
The two major factors affecting the use of language constructs in a program’s source code are likely to be driven the author’s personal habits and the demands of the model used for the application.
Measurements of C source (see table) show a surprising amount of regularity. For instance, that perennial favourite Zipf’s law shows up in Identifier name usage (see fig 130).
However, not all ’laws’ are followed so closely; for instance, Benford’s law (see fig 141) provides a poor fit for integer constants, and a slightly better fit (see fig 142) for floating-point constants.
The amount of nesting of language constructs often (e.g., fig 43, 44, 45, 184, 188, 193) has a log linear relationship. Whether this log-linear form is the result of the way that developers organize their code or is a natural consequence of solving real-world problems is an open question.
Educators will be interested in the fact that a large percentage of statements are very simple (e.g., table 192, 202, 205, 219). Concentrating on teaching the common cases will help students focus on what they will mostly encounter during program comprehension (and perhaps reduce the desire to write complicated code).
Anybody wanting to measure a different collection of C source can find some useful tools at www.knosof.co.uk/cbook/srccnt.tgz (note: a *nix based system is required).
Software Patents and Language Design
by Chris Douce
Admittedly this isn’t directly a psychology issue (or strictly a software engineering issue either) but it is one that may interest the language designers amongst us.
Can a notation or elements of a programming language be patented? I found it interesting (and also somewhat bewildering) to discover that patents were being filed against very particular aspects of language design - notably a mechanism to check a data type.
References to this topic are presented below:
Wikipedia article regarding patents
The following patent is used in the Wikipedia article as an example:
Patent application : Method of concealing partial baldness
The following patent text seems just as bewildering:
Patent application : IS NOT Operator
Acknowledgements
Many thanks go to all reviewers of this edition of the newsletter. Thanks, of course, is also extended to all contributors. Keep up the good work!