Interview: Professor Jorma Sajaniemi

By Chris Douce

There is one group of researchers that have been attending PPIG workshops with reassuring regularity.

Hailing from the University of Joensuu, Finland, the Finnish Group have carried out psychology of programming research using a number of different approaches and methods. They have adopted the engineering approach by developing tools to support programmers, have explored the sometimes controversial issue of programmer testing and entered the world of program understanding by carrying out experiments using eye-tracking systems.

More recently they have innovated in the area of computer science and programming education by introducing and evaluating the concept of variable roles, continuing earlier work in the area of program animation.

Professor Jorma Sajaniemi has agreed to be interviewed for this edition of the PPIG newsletter. As well as disseminating the fruits of his research through the PPIG series of workshops Professor Sajaniemi has also published his work in a number of other conferences and journals that will be recognisable to many: OOPSLA, International Workshop of Program Comprehension, Computer Science Education, ITiCSE.

Professor Sajaniemi, you can, without a doubt, be considered one of the PPIG regulars. Can you tell us what drew you to this field, the intersection between software engineering and human factors? Why is this area of continued interest to you and your group?

It all began in mid-80's when I was a young Associate Professor of Computer Science at the University of Joensuu. I realized that students coming to the university with a background in high-school programming courses had severe problems in acquiring principles of structured programming - an innovative programming technique at that time! The reason was 'obvious' to me: the BASIC programming language of those days.

It missed control structures and lead to spaghetti code with a lot of GOTO statements. So I wrote a Letter to the Editor for the main Finnish newspaper Helsingin Sanomat; the title was 'BASIC spoils brains'.

The next day my phone rung and there was Pertti Saariluoma, now a Professor of Cognitive Science at the University of Jyväskylä, then an Assistant of Psychology at Joensuu. He said that my conclusion was correct but the reasoning was wrong. What a nice way to meet a new person!

So we started to discuss about psychology of programming. At first we didn't even realize that many words like 'memory' and 'icon' meant totally different things to the two of us. But we could overcome these problems and eventually started to investigate psychology of spreadsheet calculation. His interest was to understand human cognition; my interest was to help the poor spreadsheet author.

In 90's I escaped university for a while and went to work in industry. Almost ruining a large software project I soon found out that what was missing in the university curriculum was Software Engineering. Escaping back to academia I introduced software engineering to our teaching.

I also realized that the problems in industry could not be solved by developing new tools and techniques in the standard way, i.e., by devising fancy things that are technically possible, but the limitations of human cognition must be recognized when designing tools and techniques.

Since then I have tried to help the poor programmer and software engineer by trying to find out ways to tailor tools and techniques to human cognition. Seeing the vast number of problems and the small number of researchers and research results - even worldwide - keeps me on this track.

When you were working in industry, can you think of any particular problems or situations that caused you to reflect on the practices you adopted as a part of your work?

One of the major problems was change management. It was not only hard to keep track of all changes but making even trivial changes was becoming almost impossible. Each change affected a number of program files, test cases, documents, training materials etc.

There were several variants of the system because of alternative database engines, operating systems, etc. A change could have different effects in different variants and a number of special cases to be considered with each change that arose. It soon became very hard to remember what files and which special cases should be checked with each change. So we had a clear example of the limitations of the human memory system!

As a solution I developed the notion of 'interactive check lists', one for each change type, that automatically opened the relevant files for inspection, propagated changes from one file to others as far as possible, and reminded of special cases to be thought of - a tool to overcome the limitation of human cognition! This tool did not utilize newest technological innovations. However, it was one of the resolutions saving the project.

It seems that you consider the development of tools (to assist the programmer) is an activity that goes hand in hand with the development of appropriate processes. Do you think process (and process evaluation) is just as important as the development of useful tools? Programmer education is, of course one of the key topics within PPIG. As a part of your teaching activities do you present different types of software engineering process?

Process control seems to be the only way to ensure product quality. If we want to avoid omissions, detect errors, stay out of update clashes etc, we must obey approved working habits and rules, i.e., we must have a well-defined process. Process improvement is hard in practice, because there are so many affecting factors starting from resistance to change to lack of appropriate tools.

Process development is also hard to approach scientifically because empirical evaluation of new process proposals is very expensive and still only indicative. To cover all this in software engineering courses requires much more time than what is usually available.

By tools I do not mean special-purpose computer programs only; a tool can be a notation (like UML), a method (like responsibility-driven design) or a process definition (like XP). Tools are supposed to help programmers and software engineers in their work or to ensure that processes are followed. Programmer education should give students understanding of the principles behind these tools so that they can adopt new tools easily.

One of the tools that I use as a part of a software development process is the spreadsheet, not only as a way of trying to calculate how long certain activities may take, but also to track bugs too. Before your work on variables, you carried out some interesting work looking at how people work with spreadsheets. Can you tell us a little about this work?

My work on spreadsheet has two tracks. The work with Pertti Saariluoma concentrated on the structure of cognition and spreadsheets were just a test-bed for the experiments. Consequently the results were interesting for cognitive psychologists rather than directly usable for helping spreadsheet authors.

An example of the results was the finding that people use visual imagery in programming work - an important result for understanding cognition but very hard to utilize in devising better tools. The other track was the development of structured spreadsheets that tried to introduce application data structures into the realm of spreadsheets. The intention was to make the mapping between program structures and application domain structures simpler. The work resulted in several prototypes but this kind of development would require a commercial producer who would take care of making a real product.

In the psychology of programming research, I see (at least) three very different foci: structure of cognition and cognitive processes; structure of knowledge representations; and contents of knowledge.

Psychologists are mostly interested in the first two categories and research has mainly concentrated on them. Computer scientists have been more interested in the second category. For example, the work of Elliot Soloway in 1980's revealed something about the structure of plan knowledge but he studied the exact contents of the knowledge only superficially.

Our research on the roles of variables belongs to the third category: we have extracted expert programmers' knowledge in detail and taught it explicitly to novices, with success. I think that this third category - contents of knowledge - is most important when building tools for programmers and deserves much more attention in future.

Your work on the roles of variables, an approach to help students understand how and where they can be used, is becoming increasingly influential. Is this an area that you are continuing to explore? More specifically, are you working on any ideas that may interest delegates for PPIG 06?

Having studied roles for four years now, we are little by little starting to understand what they really are about. However, we do not yet know what features of role-based animation makes it so powerful for learning, neither do we know why animation works so well. We are continuing our research in these areas and we hope to find answers that can be generalized to other animation environments, also. However, this type of research takes at a lot of time and I cannot give any schedule for it!

As another line of research, we are currently planning some classroom experiments with other universities and high schools, also in other countries. Our intent is to find out the applicability of roles in various contexts like in object-oriented teaching. In addition to our own research, I would also like to see independent studies of using roles in teaching.

I have always found PPIG Workshops as a great place to present on-going work (and even non-going work!) as well as final reports of quality research. As PPIG Workshop is the only world-wide annual event in psychology of programming, its proceedings should, however, be published in a more organized way. Of course, the variation among PPIG papers is huge - which is not a bad thing at all. During the last few years there have been some steps towards recognizing this variation in the publication process but I think that there still is a need for a more permanent solution.

To find out about more about Saja's work, you can visit his website.