The Work Situation in Software Development

Michael Frese, University of Giessen, Otto Behagel Str. 10F, 6300 Giessen, Germany
Wolfgang Hesse, University of MarburgHans Meerwein Str., 3550 Marburg, Germany

If one wants to improve software quality, one ought to analyse not only the quality of the software products but also the production process itself. The work situation of software developers has been analysed in an empirical and interdisciplinary study; its major results are reported here.

Some of the important results are that communication is required to a high extent, that there are negative stress effects in terms of burnout and that user participation has negative effects on project and process quality. Moreover, software developers are not as interested in the functionality of new tools as their usability; new methods like object oriented design may lead to increased demands to communicate with each other.

The work situation of software developers as a factor of software quality

If one wants to improve software quality, one should not only look at the result of the production process but also at the production process itself. Traditionally the quality of the product has been the focus of attention. Recently, this view has been complemented by taking into consideration the process quality as well. Moreover, the production process of software is not only looked at as an aspect of total quality management and as a factor of the product quality but also as an issue in its own right.

This viewpoint implies that the participants of the process become the target of research in the area of software engineering - the software developers, the project leaders, and partly those users who participate in the production process. The work situation during the production process is of major importance for process and product quality.

This was the starting point of the IPAS-project (IPAS is a German acronym and stands for "interdisciplinary project on the work situation software development). In all 29 software development projects from 19 German and Swiss firms were studied. The means size of the projects was 10 members; the total sample comprised 200 software developers. All of them filled out a questionnaire and were interviewed for several hours.

The software produced by these projects covered a broad application domain, for example administration, banks, insurances. Military or academic projects were not included because they do not produce for a free market

Our framework for research

The basic framework for our interdisciplinary project is presented in Table 1. The idea was to cross the different perspectives of the disciplines working together in this project (computer science, work psychology and industrial sociology). Our original framework was modified for this presentation because we excluded the sociological part from this article - a column on project management. The rows of this framework consist of categories from work psychology that have been shown to be important to describe work situations, the columns are related to software-technical criteria that are important in software engineering. These two dimensions lead to 15 problem areas which will be used to describe the results of our study. This article presents an overview of the results.

Software technical categories / Psychological categories	Relationship with user	Development	Methods and tools
Coping with complexity	Familiarising oneself with user applications areas	Appraisal of one's job complexity	Use of tools and developers' requests
Cooperation and communication	Difficulties with user participation	Communication as major part of development	Influence of new methods on communication
Job discretion	Factors influencing job discretion: standards, guidelines, change requests, flexibility	Correlation between job discretion and burnout	Influence of job discretion on acceptance of tools
Qualification	Qualification of software developers in the application area	What characterise excellent software developers	Learning to use methods and tools
Stressors	Developer's stress through user participation	Stress and burnout: software development as challenge or stress factor	Effects of changing methods and tools

Framework for research

Results and discussion

1. Coping with complexity

The necessity to cope with the complexity of the software development process is an important problem for software developers and their managers. Most likely, complexity of this process will increase in the future. While new programs and tools render comfortable metaphors or graphical user interfaces, the user of such programs and tools for the design process is confronted with a rapidly growing number of products, difficult decisions, incompatible interfaces, etc.

There are ever shorter innovation and production cycles. Once one has to know one tool, there is already a new version or a new product on the market. This leads to new (learning) problems if these new tools are used. Thus, one result of our research is that usability and easy learnability are more important criteria for software designers than better functionality (cf. 1.3 below).

There are two strategies to cope with complexity: one can either reduce complexity or learn to live with it. In the software projects studied we found both strategies. On one hand, there was problem oriented modelling, a coherent procedure with one method (e.g., with an object oriented approach) or the use of CASE tools - all of these are attempts to reduce complexity. On the other hand, psychological research showed that complexity reduced stress and increased motivation in the software developers (cf. l.2)

1.1 Qualification of software developers in the application area

One important aspect of complexity in the work of software developers is the necessity to get to know new application areas and to find solutions that are adapted to the specific user needs. Current tendencies aim at a more highly integrated development process ranging from functional design to technical design and implementation. The pressure to produce software more efficiently and with fewer costs will most probably increase in the future. This implies that reusability will be a highly important topic. Reusability does not only refer to software modules but also to function design, user models, and even to analysis documents. This leads to new demands on software developers to deal with complexities not only in their own technical area but also in the areas of functional design, user modelling and analysis of particular application areas

1.2 Appraisal of job complexity

Since software development is a highly complex undertaking, one often draws the conclusion that its complexity should be reduced. This is probably true in certain cases. However, our results suggest that this should not be a general strategy. Work complexity is often something very positive for the software developers. For example, software designers with highly complex jobs show less burn-out. They are also prouder of their work and their team is prouder than software designers with jobs of little complexity. Thus, a reduction of complexity may have counterproductive effects.

It is useful to differentiate between complexity of tools on one hand and complexity of tasks and activities on the other hand. Tool complexity is very often seen as something negative, task and job complexity are positive aspects of the work place. Tools should, therefore, not reduce the overall complexity of the job; they should only contribute to a reduction of routine activities or lead to a reduction of "detours". Examples for detours are activities that are not directly linked to the work tasks, e.g. mounting a new tool. This allows the software developers to concentrate the intellectual challenges in work.

1.3 Use of tools and developers' requests

Various parts of our research were concerned with tool use: which tools were used for doing which tasks, what did the software developers want from tools, effects of tools, etc.. The results show that there is a large discrepancy between theory and practice. While the CASE market offers tools with sophisticated graphical user interfaces, many software developers still have to deal with VSAM, CICS or line editors.

A comparison between what software developers want and what they have shows that typical tasks like coding, editing, and debugging are adequately supported by tools. On the other hand, the software developers would like to have better tools in the areas of documentation, graphical support (especially analysis and specification tools), test support, generators and project management.

In general, the developers report to be well supported by the tools available. However, the importance of usability was higher than the functionality of the tools. Forty per cent saw "easy to learn" and "easy to use" as the most important characteristics of a tool. Functional aspects like "without errors, "well adjusted to task", "easy to combine with other tools" or "performance" were only mentioned by 5% to 8% as important. The wants and requests of software developers are relatively modest. Only those designers who had got to know other tools in other projects or in their studies presented suggestions for improvement. The more they have used tools the more they thought that their tools are flexible enough to change them. Tools may be important but they are clearly not more important than motivational factors and social support by co-workers and supervisors.

2. Communication and cooperation

2.1 Difficulties with user participation

Presently, there are many arguments for a higher degree of user participation in the design process, e.g., through prototyping Often, only the advantages of such an approach are presented and potential disadvantages are not discussed. We also expected that user participation would lead to positive consequences. However, the data prove the opposite.

We found that the efficiency of the software process, the changeability of the product, the quality of the product, time efficiency, etc. were all reduced in projects with high user participation. In other words, the users seem to disturb the development process. There are more change requests in the projects with user participation. The innovativeness of these projects is also seen to be lower by the software developers. These results are not the opinion of just a few software developers. They are supported by the majority of the software designers in the projects with high user participation.

Our results do not mean, however, that user participation is harmful per se. But it does show that there may be more dangers and difficulties in user participation than what is known at this point. User participation can lead to frictions, to additional tasks and demands. These problems have to be investigated and adequate strategies have to be developed to deal with them. At the very least, one has to take into account that these problems can appear with user participation and rapid prototyping. In order to cope with these matters a certain amount of time and budget should be allocated when user participation is planned. In addition, software developers' orientations have to be changed. As long as user participation is not defined to be a central task for software developers, user participation will just lead to disagreeable add-on demands. Only after a new orientation is introduced can software designers look positively at change requests by the users.

2.2 Communication as a major part of software development

It is now generally known that the solitary programmer is a rather exceptional case. Nevertheless, many trainings and university curricula do not sufficiently take into consideration the fact that programmers have to work in teams (at least not in Germany). Interestingly, programming is only a very small part of software development (about 10% of the time) while all the social activities, e.g. exchange of information, consulting, team discussions, etc., make up a much larger percentage of the developers' work day (about 40% of the work tasks is in some way socially oriented).

Can we conclude that software development is a social profession? This is certainly not the case. But the social component is of utmost importance not only for team leaders but also for the team members. Most developers' tasks have a social component, e.g. specification, design, testing, system support, technical support, review sessions, coordination, adjustment of interfaces, etc.

All this requires much social competencies. The developers have to react flexibly when different communication requirements appear. These requirements may mean that one has to moderate a group, to structure ideas and to support other people or to criticise them. Conflicts have to be coped with and different communication strategies have to be followed in discussions, depending upon the other's knowledge and prerequisites. All of these competencies are not acquired through normal academic training courses. It is of particular importance not to present a general sort of social competence training but to offer specific courses integrating technical skills in the field of computer science with communication skills.

2.3 The influence of new methods on communication

New methods and tools may considerably affect cooperation and communication in a team. For example Parnas principle of information hiding or the data abstraction method may lead to a bureaucratisation in software development and a reduction of communication. In contrast, a change to an object oriented method may lead to the opposite result.

The following remarks are not based on statistical analyses because there were oddly a few projects in our sample that used object oriented design methods. However, it was our impression, that there is particularly strong need for communication and cooperation in such projects. This is probably due to different software structures. While the data abstraction method exclusively connects different modules through import/export relationships, this is not the case in object oriented design where inheritance relationships play an equally important role. The data abstraction method allows a design by developers who work relatively independently from each other. While division of labour is necessary in object oriented design as well, the various developers have to communicate a lot, e.g. on features inherited from each other. Usually, a purely formalised communication, e.g. the exchange of formal specifications, is not sufficient because intensive and frequent talks about the implications of various decisions in the design process are necessary in object oriented design.

3. Job discretion

Job discretion implies that a person has possibilities to change things at a work place. For example, if job procedures are not rigidly prescribed, if software developers have some influence on what kinds of tools are used, if they can decide how they are doing their job and if they can decide at what time they do certain tasks, their job discretion is high.

There are essentially two management approaches to job discretion. One implies that job discretion will only lead to a reduction of productivity and that management should organise work in such a way that there is little job discretion. This is the Tayloristic approach. The other approach is based on modern work psychology and it implies that the people at work will only be fully motivated to work if they can use their abilities and skills in their work. This implies that job discretion should be high.

3.1 Correlates of job discretion

Different software designers have different degrees of job discretion. One issue is the flexibility and the changeability of the programs. If there is a high degree of changeability of the program, one can, e.g., deal more quickly and adequately with change requests.

In this connection it is of interest to know who is most often responsible for changes - is it the contractor of is it the software developers themselves. If it is the former, there is little scope of action (and hence little job discretion), if it is the software designers, change requests are themselves the result of a high degree of job discretion. Our results were surprising: apparently a large part of the change requests stems from the software developers. About 40% of the change requests were due to internal sources. Management or other developers in the team were responsible for 14% of the change requests. However, the most important cause of change requests was the development of new solutions by the individual software developers him- or herself (25%). Job discretion is used here to develop and improve one's work and one's solutions. No wonder that job discretion is seen as a positive factor in work psychology that contributes to higher product and process quality.

3.2 Correlation between job discretion and burnout

Job discretion is not only an important factor influencing performance, it is also related to burnout. The higher the job discretion is, the lower is the burnout for software developers. If there is a high degree of rigid division of labour, this usually reduces job discretion. Moreover, there is a relationship between job discretion and work complexity. If there is little complexity, there is also little that can be decide in work.

Since burnout probably has an impact on productivity - be it through absenteeism or through little motivation for work - a high degree of job discretion is an important productive factor.

3.3 The influence of job discretion on acceptance of tools

One of the issues in our research project was to study the acceptance of tools by the software developers. In general, the tools were quite well received. The software developers think most highly of simulation tools, low level editors and project management tools. The tools that are perceived to be less good are project libraries. This may be due to the fact that these tools can only be used adequately with a high degree of experience.

There was also an interesting interaction of job discretion and the perceived usefulness of the tool. Perceived usefulness of the tool was a general perception by the software developers of how good the tool was adjusted to the tasks and how usable it was. In general, usefulness of the tool also implied that stress effects were minimised. This fact was mitigated by job discretion, however. Under conditions of high job discretion, usefulness of the tool was related to reduced stress effects. If the job discretion was low, there was little relationship to stress effects.

Thus, the usefulness of the tool seems to have a positive impact only if the general conditions in the job allow the person a lot of freedom. If this freedom is low, the usefulness of the tool does not help the software developers to cope with the stress effects.

4. Qualification

4.1. Qualification of software developers in the application area

Software developers have to learn new things in every project. In most cases, this has to be done without formal training. Of particular importance is the knowledge acquired about the area of application. To gain this knowledge the software developer should have the following competencies:

• to learn a different conceptual system in which he or she has to be the translator,
• to be able to pose clear and sensitive questions,
• to separate plausible from implausible hypotheses and essential from unessential information,
• to discover structures which may be so routinised in the area of application that people will not be able to verbalise them any more,
• to distance oneself from one's own egocentrism and to put oneself into the shoes of somebody else; this implies that one has to be able to distance oneself from one's own discipline and to take the perspective of what the users have been saying,
• to develop criteria to find out whether one has been understood or whether or not one has understood what the users have been saying,
• to make abstract concepts concrete, i.e. to find examples for abstract examples in the area of application.

Moreover, the knowledge in the area of application has to be reconciled with the requirements of the project. This means, for example, that the software developer has to analyse requirements of the application area and whether they can be realised technically.

Thus, software developers need to show considerable qualifications. At the same time, they rarely receive formal training for many of these skills. This implies that they have to learn strategies to learn by themselves. These strategies may be one of the most important factors of software developers' success in their job - again it is something that has received little attention.

4.2 What characterises excellent software developers?

In order to find out which qualifications and competencies software developers need to do their job well, we have to identified excellent software developers in the projects studied. This was done with a procedure used quite often in work psychology: peer nominations. All people were asked to identify the best software developer in their team. Those people identified by two of their colleagues were taken to be excellent software developers. Moreover, the software developers were asked what characteristics makes them excellent. What characterises these excellent in comparison to average software developers?

The three most important characteristics were: technical competence, ability to work in team, work style. Technical competence implies a high degree of professional experiences, an ability to recognise and solve problems quickly and a high degree of knowledge about the particular project (e.g. knowledge to whom one can address which questions, which information can be received where, the structure of the system to be developed, knowledge of previous errors and wrong decisions and why are things done the way they are done). The ability to work in teams implies that it is fun to work with this particular person, that this person can communicate effectively and that he or she is willing to work together with others. A good work style is characterised by using systematic procedures at work, by being independent in work and by being team oriented.

It is interesting to note that the excellent software developers did not have a higher job tenure but they had more intensive experiences. They had participated in more projects and they knew more programming languages. They are asked to participate in more meetings and they are asked more questions by the other software developers. Thus they have to communicate more (and are apparently better able to communicate) than the average software developers. Again we find the importance of communication skills. The excellent software developers are the natural leaders of their teams. Sometimes they are just the informal leaders, but they are also often made to become supervisors in due time.

4.3 Learning to use methods and tools

The qualification of software developers for the use of methods and tools is an important prerequisite to do the job well. Our studies showed that learning while doing the job prevails rather than formal and systematic training. In about 40% of the cases, the use of methods and tools was learned on the job; the software developers received some formal training in only about 16% of the cases.

However, there are clear differences between the academically trained computer scientists and the non-academic software developers. The computer scientists had some knowledge on methods and tools in 41% of the cases; this was the case for only 26% of the software developers who were not academically trained. This reinforces the importance of self-discovery learning in software development. Those who have learned how to learn will be at an advantage. To support this "learning to learn", one would have to teach learning techniques, self-organisation, etc..

5. Stressors

5.1 Developers' stress through user participation

There is a clear correlation between user participation in a project and the number and intensity of stressors impinging on the software developers. In projects with user participation, there are more stress factors than in projects without user participation. At first sight, this result may be surprising. However, it makes sense that software developers, who have to work under high time pressure anyhow, will have more stress if their normal work is interrupted and additional user requirements have to be met on top of their normal work. Again, this shows that user participation is not as unproblematic as it seems.

5.2 Stress and burnout: software development as challenge or stress factor

From the standpoint of work psychology, the work places of software developers are in general quite good. The software developers have challenging tasks, usually of high significance and importance. These tasks are complex enough and it is possible to interact socially in the job. Nevertheless, there are stress factors which may contribute to psychological impairment even in this sector that may seem to be privileged: too much work, frequent interruption, unclear or late information, career pressure and pressure to outperform.

Many software developers and project leaders checked in the questionnaire that they have to deal with an enormous work load and that their work is interrupted again and again. They have to work overtime frequently and cannot compensate this with additional leisure time. Most overtime has to be done by project leaders and user delegates in the software team. The latter have a particular high work load. At the same time, they have to work both for the project and in their normal duties. An added burden is the pressure from their constituency (the users to be) and the pressure to be part of the software team.

The burnout syndrome is of particular importance for software developers. Burnout implies that a person feels exhausted and is not able to identify with his or her work any more and that he or she has the feeling, that one's ideal, ideas and one's potential cannot be realised. One has to assume that burnout may contribute to loss of motivation at work, to psychosomatic problems and to a higher degree of absenteeism. Thus, burnout probably does not only reduce motivation but also productivity. A finding supporting this claim is that excellent software developers show less burnout than the average ones.

Burnout has a clear cut relationship to the stressors of software development: the higher the stress factors at work, the higher the burnout. Moreover, those people with higher job discretion and higher complexity of work also show less burnout. Similar effects appear with group climate: teams that are democratic, more open for critique and less authoritarian also show less burnout among their members.

5.3 Effects of changing methods and tools

The high degree of innovation in the area of methods and tools can be one stress factor as well. While tools are supposed to support the work of software developers, they often produce the opposite effect. This may be the major reason why software developer attaches the most importance to the criterion "learnability" when they judge tools (c.f. 1.3).

6. Conclusion

Our project has dealt with an area that has not been frequently or systematically researched. From a psychological perspective some surprising findings were the high degree of communication requirements in the job of software developers, the importance of burnout as the major effect of stress at work, the cohesive picture of excellent software developers and the negative impact of user participation on product and process quality. Some of these results have been reported by other as well. The most troubling finding is certainly that user participation may have a negative effect in the design process.

From the standpoint of computer science, important findings were that software developers are less interested in the functionality of new tools but rather in how easily they can be learned. Moreover, the well-known gap between software developers and users appeared again in our research. New methods, e.g. object oriented design, may lead to a higher necessity to communicate well. The question the of complexity of the tools versus the complexity of the job is certainly something to be considered in the application and development of new tools. Applying new software engineering techniques always implies that the work situation of software developers is changed for the better or for worse. Thus, the change of the software developers' jobs is an important factor to be considered in the area of software engineering.

---

Click here to view the complete list of Methods & Tools articles

This article was originally published in the July 1995 paper issue of Methods & Tools