motivation in software engineering: a systematic literature review

Available online at www.sciencedirect.com

www.elsevier.com/locate/infsof

Information and Software Technology 50 (2008) 860–878

Motivation in Software Engineering: A systematic literature review

Sarah Beecham a,*, Nathan Baddoo a, Tracy Hall a, Hugh Robinson b, Helen Sharp b

a School of Computer Science, University of Hertfordshire, College Lane Campus, Hatfield, Hertfordshire AL10 9AB, UKb Department of Computing, Faculty of Mathematics and Computing, The Open University, Walton Hall, Milton Keynes, MK7 6AA, UK

Received 13 July 2007; accepted 29 September 2007Available online 17 October 2007

Abstract

Objective: In this paper, we present a systematic literature review of motivation in Software Engineering. The objective of this reviewis to plot the landscape of current reported knowledge in terms of what motivates developers, what de-motivates them and how existingmodels address motivation.

Methods: We perform a systematic literature review of peer reviewed published studies that focus on motivation in Software Engi-neering. Systematic reviews are well established in medical research and are used to systematically analyse the literature addressing spe-cific research questions.

Results: We found 92 papers related to motivation in Software Engineering. Fifty-six percent of the studies reported that SoftwareEngineers are distinguishable from other occupational groups. Our findings suggest that Software Engineers are likely to be motivatedaccording to three related factors: their ‘characteristics’ (for example, their need for variety); internal ‘controls’ (for example, their per-sonality) and external ‘moderators’ (for example, their career stage). The literature indicates that de-motivated engineers may leave theorganisation or take more sick-leave, while motivated engineers will increase their productivity and remain longer in the organisation.Aspects of the job that motivate Software Engineers include problem solving, working to benefit others and technical challenge. Our keyfinding is that the published models of motivation in Software Engineering are disparate and do not reflect the complex needs of SoftwareEngineers in their career stages, cultural and environmental settings.

Conclusions: The literature on motivation in Software Engineering presents a conflicting and partial picture of the area. It is clear thatmotivation is context dependent and varies from one engineer to another. The most commonly cited motivator is the job itself, yet wefound very little work on what it is about that job that Software Engineers find motivating. Furthermore, surveys are often aimed at howSoftware Engineers feel about ‘the organisation’, rather than ‘the profession’. Although models of motivation in Software Engineeringare reported in the literature, they do not account for the changing roles and environment in which Software Engineers operate. Overall,our findings indicate that there is no clear understanding of the Software Engineers’ job, what motivates Software Engineers, how theyare motivated, or the outcome and benefits of motivating Software Engineers.� 2007 Elsevier B.V. All rights reserved.

Keywords: Motivation; Software Engineering; Software Engineer; Characteristics; Personality; Systematic literature review

1. Introduction

In this paper, we present findings from our systematicliterature review on motivation in Software Engineering(SE). Since Bartol and Martin’s literature review in [2] nocomprehensive body of research has been published to pro-

0950-5849/$ - see front matter � 2007 Elsevier B.V. All rights reserved.

doi:10.1016/j.infsof.2007.09.004

* Corresponding author.E-mail address: [email protected] (S. Beecham).

vide a complete picture of the available material on motiva-tion in Software Engineering. By updating work in thisarea we help SE managers, Software Engineers and inter-ested researchers to determine the current state of researchin Software Engineering motivation. Our systematicapproach to analysing published studies enables us to iden-tify reliably where the literature has recurring themes,where it presents conflicting findings, and where are theregaps in the existing body of work.

mailto:[email protected]

S. Beecham et al. / Information and Software Technology 50 (2008) 860–878 861

Motivation in Software Engineering is reported to havethe single largest impact on practitioner1 productivity [4]and software quality management [34], and continues tobe ‘undermined’ and problematic to manage [37]. Whilethere is increasing recognition amongst practitioners andthe academic community that motivation is an importantissue, no systematic literature review has been undertakento bring together the published work of motivation in aSoftware Engineering setting [35].

Motivation is increasingly cited as a particularly perni-cious people problem in Software Engineering. In DeM-arco and Lister’s [19] survey, motivation was found to beone of the most frequently cited causes of software devel-opment project failure. The Standish Report [42] amplifiesthis finding by reporting that having access to competent,hard working and focused staff is one of ten success criteriafor software projects. As McConnell [34] points out,

‘‘Motivation is a soft factor: It is difficult to quantify, andit often takes a back seat to other factors that might beless important but are easier to measure. Every organisa-tion knows that motivation is important, but only a feworganisations do anything about it. Many common man-agement practices are pennywise and pound-foolish,trading huge losses in motivation and morale for minormethodology improvements or dubious budget savings.’’

Some studies in this area suggest that conventionalapproaches to motivation within the industry might be out-dated. They have concentrated on rewards and recognition,e.g. [38], whereas some experts have identified SoftwareEngineers as having a distinctive personality profile [6] thatare instead motivated by the nature of the job, e.g. techni-cal success and challenging technical problems [43,39].

Given the importance of motivating Software Engineers,we conduct a systematic literature review of what motivatesSoftware Engineers and whether Software Engineers areindeed a homogeneous group with similar needs. A system-atic literature review evaluates and interprets all availableresearch relevant to a particular research question or topicarea. It aims to present an evaluation of the literature rel-ative to a research topic by using a rigorous and auditablemethodology. We have followed guidelines derived fromthose used by medical researchers, adapted and appliedby Kitchenham et al. [30,31] to reflect the specific problemsof Software Engineering research. We summarise evidencethat establishes what motivates Software Engineers andhow existing theoretical frameworks represent motivationin Software Engineering. We look to the literature toanswer five research questions:

1 The way Software Engineer (as a practitioner) and Software Engineer-ing (as a field) have been referred to over the 26 years covered in this studyhas evolved significantly. IT, IS, SE, analysts, developers, programmers areexamples of some of the terms used for the practitioner role/field. In thissurvey, we use the term ‘Software Engineer’ (SE) to refer to any of theseroles and Software Engineering to refer to the field. However, whenquoting or referring to a particular paper, we use the term used in the study.

RQ1: What are the characteristics of Software Engineers?

RQ2: What (de)motivates Software Engineers to be more

(less) productive?

RQ3: What are the external signs or outcomes of

(de)motivated Software Engineers?

RQ4: What aspects of Software Engineering (de)moti-vate Software Engineers?

RQ5: What models of motivation exist in Software

Engineering?

In this review, the literature often characterises SoftwareEngineers (SEs) as a homogeneous group of high achievers[9,6]. These studies suggest that Software Engineers aresomehow different to non-Software Engineers, a view rein-forced by Wynekoop and Walz [44] who found ‘‘importantdifferences in personalities exist between IS employees andthe general population’’. On the other hand, Ferratt andShort [22] question the existence of differences betweenIT and non-IT employees. They found that IT employees(including IT managers) within the technical–professionalsub-occupations were not more motivated by achievementneeds than corresponding subgroups of non-IT employees.Although they did find that meaningful work was the high-est motivator for these IT subgroups.

Couger and Zawacki’s [9] seminal work on motivationin software engineering was conducted over 20 years ago.Yet, this work has been used throughout the period of thisreview as the central model of Motivation in SoftwareEngineering. The environment for software engineeringhas changed considerably since that time, e.g. with theincrease in outsourcing, open source development, newtechnical concepts and languages, new lightweight develop-ment methods and so on. So, in this review we considerwhether this work is still as valid as it was.

This paper is organised as follows. In Section 2, wedescribe the method we used for our systematic literaturereview, this involves producing and following rules in aprotocol that is independently validated. We also reporton the quality of the included papers in this section. Section3 presents results of our synthesis of the literature, includ-ing geographical spread, temporal aspects and publicationdetails. Section 4 reports the results of our synthesis ofidentified themes based on our five research questions. InSection 5 we discuss our key findings. Section 6 presentssome limitations of this study, in Section 7 we give sugges-tions for further research and finally in Section 8 we presentour conclusions.

2. Methods

2.1. Introduction

In accordance with systematic review guidelines [30] wetake the following steps:

1. Identify the need for a systematic literature review [35]2. Formulate review research question(s)

862 S. Beecham et al. / Information and Software Technology 50 (2008) 860–878

3. Carry out a comprehensive, exhaustive search for pri-mary studies

4. Assess and record the quality of included studies5. Classify data needed to answer the research

question(s)6. Extract data from each included study7. Summarise and synthesise study results (meta-analysis)8. Interpret results to determine their applicability9. Write-up study as a report.

These steps are detailed in our protocol (See [3] or http://homepages.feis.herts.ac.uk/ � ssrg/MOMSEProto.htm).To ensure we did not overlook any important material, addi-tional searches were performed directly on key conferenceproceedings, journals and authors. Also, correspondingauthors of main texts were e-mailed directly to find outwhether they had any material in press. Furthermore we con-ducted secondary searches based on references found in ourprimary studies. All researchers were prompted to recordadditional references for follow up work on the primarystudy ‘results’ form.

2.2. Pilot study

We developed our protocol by running three separatepilot studies involving four researchers who performedsearches based on rules given in the protocol. Our firstpilot study uncovered several problems with the proto-col which proved too complex and time-consuming toadminister within reasonable timescales; changes wereimplemented iteratively and two further pilots were con-ducted to fully test the process. The pilot studies servedto:

a) reduce the complexity of the process by adaptingEndnote to record all quantitative details about thestudy, demographics, decision stages, and status;

b) clarify and re-word our research questions;c) create a traceable process where we can identify the

source of each study;d) increase the number of search terms to include known

studies;e) create a repeatable measure of study quality;f) refine a ‘results’ form to record how study directly

answers our research question(s);g) scope the review, e.g., the initial list of 2,000 papers

included many studies on cognitive motivation andgender differences that for pragmatic reasons weexcluded from our review, whereas the pilot high-lighted some studies on employee retention and turn-over that we included in our review.

The resulting protocol was peer reviewed by ProfessorBarbara Kitchenham, an independent expert in systematicreview development in Software Engineering. This externalvalidation gave us additional confidence in the final ‘work-ing’ version of the protocol.

2.3. Search terms

Our five research questions contain the following keywords:

‘‘Software Engineer, Software Engineering, Motivation,De-Motivation, Productive, Characteristics, outcome,Model’’. A list of synonyms was constructed for each of thesewords, as in the example for research question 1 which con-tains keywords ‘Software Engineer’ and ‘Characteristics’:

keywords ((engineer* OR developer* OR professional*OR programmer* OR personnel OR people OR ana-lyst* OR team leader* OR project manager* OR practi-tioner* OR maintainer* OR designer* OR coder* ORtester*) AND characteristic* OR types OR personalityOR human factors OR different OR difference* OR psy-chology OR psychological factors OR motivator* ORprefer* OR behavio*r*)

Our lists of search terms were adapted to match eachresearch question and the individual requirements of eachof the search engines on our resource list; some searchengines allowed Boolean searches, some did not, someallowed nesting, whereas others did not. For this reasonwe created tables of search terms for each search engine.

2.4. Resources searched

The following databases were searched using the keywords noted in the ‘search terms’ section above:

• ACM Digital library• EI Compendex• Google scholar• IEEE Explore• Inspec• ISI Web of Science• ScienceDirect• UH University’s electronic library (voyager.herts.ac.uk)

To ensure we did not overlook any important material,additional searches were performed directly on key confer-ence proceedings, journals and authors. Also, correspondingauthors of main texts were e-mailed directly to find outwhether they had any material in press. Furthermore we con-ducted secondary searches based on references found in ourprimary studies. All researchers were prompted to recordadditional references for follow up work on the primarystudy ‘results’ form.

2.5. Document selection

The selection of material for our SLR is based on thefollowing inclusion and exclusion criteria:

We include texts that:

• directly answer any one or more of our research questions;• were published in years: 1980 – June 2006;

http://homepages.feis.herts.ac.uk

http://homepages.feis.herts.ac.uk


• relate to any practitioner directly producing software;• focus on de-motivation as well as motivation;• use students to study motivation to ‘develop’ software;• focus on culture in terms of how IT personnel are

motivated in different countries or in different soft-ware environments (e.g. Open Source Systems, Agile,traditional);

• focus on ‘satisfaction’ in Software Engineering. Weinclude satisfaction as it is often used to measure SoftwareEngineer motivation. For example, satisfaction is consid-ered in great detail in the Job Diagnostics Survey for DataProcessing Personnel (JDS/DP) tool [8] that is used exten-sively to measure Software Engineer motivation.

We exclude texts

• in form of books and overhead presentations;• relating to cognitive behaviour;• external to Software Engineering;• focussing on company structures and hierarchies unless

expressly linked to the individual engineer’s motivation;• on motivating students to learn – even if they are IT

students;• Opinion pieces, viewpoints or purely anecdotal.• on software managers (e.g. Chief Information Officers)

not directly producing the software• on IT group/team dynamics that look at groups rather

than individual motivation• on gender differences (too low level)

Table 2Criteria for assessing empirical studies

Data collectionMethod

Score (Sample No)

Questionnaire/Survey

Unit = 1 person j <5 = 0; 5 < 50 = .5; >50 = 1(dependent on depth)

Face to faceinterviews

Unit = 1 person j <3 = 0; 3 – 5 = .5; >5 = 1(dependent on depth)

Observation Unit = 1 person j <3 = 0; 3 – 5 = .5; >5 = 1(dependent on depth)

Focus Groups Unit = Group j <3 = 0; 3 – 5 = .5; >5 = 1(dependent on depth)

2.5.1. Repeated studies

Before accepting a paper into the review we check forrepeated studies to ensure there is no duplication; forexample if the same study is published in two differentjournals with different first authors, only one studywould be included in the review; usually the most com-prehensive study or the most recent study. Before accept-ing a paper into the review we check for repeated studiesto ensure there is no duplication. For example, if thesame study is published in two different journals withdifferent first authors, only one study would be includedin the review. Where we need to make this choice, weinclude the most comprehensive study or the most recentstudy.

Table 1Quality Assessment

Assessment criteria Score

Does study report clear, unambiguous findings based on evidence& argument?

Is sample unbiased?Could you replicate study?Number of participants?For a questionnaire, what is the response rate?Is the paper well/appropriately referenced?%

2.6. Study Quality Assessment Checklists

Each accepted study is assessed for its quality against achecklist (Tables 1 and 2). The assessment measures wereagreed by the team of experienced researchers and vali-dated by our independent reviewer. However, the scoringis a heuristic only - to be used as a guide where no studyis rejected on the basis of its quality score. For a fair com-parison across studies we normalised the data by recordingthe percentage score.

Quality scores for the 92 papers are given in Table 3:

2.7. Data extraction and synthesis

We used Endnote version 9 (www.endnote.com) torecord reference details for each study. How each studyanswers the research question(s) was recorded on a sepa-rate results form. We synthesised the data by identifyingthemes emanating from the findings reported in eachaccepted paper. These identified themes gave us the catego-ries reported in our results section. In our results section wepresent frequencies of the number of times each theme isidentified in different studies. We give each occurrence thesame weight. The frequencies merely reflect how manytimes a given characteristic or motivator is identified in dif-ferent papers, not how important it may be.

Sensitivity analyses were performed on these studiesbased on population, location, year and type of study.The sensitivity analyses gave us information on where thedata might be biased. They are also reported in our resultssection. Our protocol provides full details of this process.

Response options for Score

Yes = 1/No = 0

Random Sample = 1/Non-random sample = .5 Not representative = 0Yes = 1/No = 0See scores -Table 2 Sample size :No response rate given = 0 Over 80% = 1/Under 20% = 0/Between = .5Yes = 1/Moderately = .5/No = 0Enter % score in Quality assessment field in Endnote

http://www.endnote.com

Table 3Quality scores of Accepted Papers

QUALITY (scores) Total

Poor (<26%) Fair (26%–45%) Good (46%–65%) Very Good (66%–85%) Excellent ( >86%)

Number of Studies 6 10 32 32 12 92Percentage of papers �6.5% �10.5% �35% �35% �13% 100%

Over 82% of papers included in our literature review have quality scores that are good to excellent.


2.8. Document Retrieval

Our searches elici ted over 2000 references. Evaluatingthe title and abstract enabled us to reject approximately1500 of these. We then looked at 519 papers in full to estab-lish a final list of 92 papers. The different stages involved inthe selection process are shown in Table 4.

2.9. Validation

We performed two validation exercises:(A) Inter-rater reliability: We ran an inter-rater reliabil-

ity test on the 519 paper references we found in our initialsearch. A group of primary researchers looked at each ofthese papers in greater detail (9 papers proved unobtain-able). Ninety-five papers were accepted by the primaryresearchers. An independent researcher looked at 58 ran-domly selected rejected and accepted papers (approx every10th paper from an alphabetical list of the 519 papers). A99.4% agreement was recorded with the original assess-ments. This high level of agreement gives us considerableconfidence in our acceptance/rejection decisions.

(B) Independent assessment: We performed a final vali-dation exercise on the 95 ‘accepted papers’. An indepen-dent expert in motivation in Software Engineeringrecorded how each paper addressed our research questions.Again there was a high level of agreement between the pri-mary researchers and the independent expert (99.8%), andany disagreements were discussed. There were only threepapers that could not be agreed on, and these went to arbi-tration with a third, independent researcher who deter-mined whether the papers should be included and howeach study addressed our research question(s). This processresulted in 100% agreement. Three of the accepted papers

Table 4Papers reviewed and validated

Selection Process # Papers P

Papers Extracted from Databases <2,000 nSift based on Title and Abstract 519 nPapers – full versions available [519–19] 500 (Papers accepted (by primary researchers) 94Papers rejected by independent researcher (validation 1) 93 [

aPapers added by independent researcher (validation 1) 95 [

pPapers rejected in Validation 2 (92 papers remain in our review) 92 A

r

The next section explains how we validated each stage of the selection proces

were rejected as a result of this exercise, leaving 92 papersfor inclusion.

3. Results – background

3.1. Type of study

Fig. 1 shows that out of the 92 studies, 86% are empir-ical, i.e. findings are based on direct evidence or experi-ment. The 11% theoretical or conceptual studies arebased on an understanding of the field from experienceand reference to other related work. There are a small num-ber of studies (3%) that are either reviews of the literatureor secondary studies, where empirical work is re-examined.

Data collection methods used in the empirical studiesinclude: surveys and questionnaires, field studies, struc-tured and semi-structured interviews (face-to-face and bytelephone), analysing results of programming tests, datareviews, case studies, focus groups and controlledexperiments.

Out of the 79 studies that are empirically based, only fivestudies do not include questionnaires. Fig. 2 shows howthese data collection methods are divided with 94%(78% + 16%) of the empirical studies employing question-naire survey instruments.

3.2. Temporal view of publications

Fig. 3 shows that over the last 26 years there is a recentincrease in published papers covering Software Engineercharacteristics and motivation in Software Engineering.

This recent increase may be a reflection of a growingawareness of the importance of motivation in SoftwareEngineering. Alternatively, this increase may just match ageneral rise in published papers in Software Engineering.

apers used in validation

/a/a58 papers randomly selected from this set for validation 1)

1 paper rejected from the 58 paper sample that formed part of the 94ccepted papers]2 papers accepted out of the 58 randomly selected papers that werereviously rejected by primary researchers]ll 95 papers assessed and qualitative forms completed by two independent

esearchers – 3 rejected

s.

empirical86%

theoretical11%

literature review3%

Fig. 1. Types of studies in our accepted papers.

78%

16%

1%

5%

questionnaire/survey

multiple data collectionmethods withquestionnaire

multiple data collectionmethods withoutquestionnaire

other

Fig. 2. Data collection methods used in the empirical studies.

NU

MBE

R O

F PA

PER

S

KEY JOURNALS AND CONFERENCE PROCEEDINGS

05

101520253035404550

SIGCPR

IEEEPROCS

INF &MAN

COMM OFACM

MIS OTHERS

Key: SIGCPR = ACM Special Interest Group for Computing Personnel Research/ IEEE Procs = IEEE Proceedings/ INF & MAN = Information and Management; JSS = Journal of Systems and Software

JSS

Fig. 4. Publication sources of our included studies.


3.3. Data sources

Fig. 4 gives a breakdown of where our 92 papers arepublished. The majority are published by the special inter-est group on computer personnel research with fewerpapers reaching the more widely known journalpublications.

3.4. Geographical distribution of papers

A high percentage of the empirical studies in our revieware concentrated on work carried out in the USA (56%), asshown in Fig. 5.

05

1015202530354045

1980-84 1985-1989 1990-1994 1995-1999 2000-2005/6Num

ber o

f pap

ers

(Tot

al 9

2)

Fig. 3. Number of papers included in the review by 5 year intervals.

Seventeen countries are represented, and although thenine global studies involve all continents, countries suchas India are not well represented in the literature. It is clearthat when we synthesise findings from all the studies we aregiving a predominantly Western view of motivation inSoftware Engineering.

4. Results – motivation in software engineering

This section reports on how the literature representsmotivation in Software Engineering. Fig. 6 gives an over-view of how our research questions work together to givea comprehensive view of our topic. Citations for the 92papers included in this section are given in numeric formwith a bibliography in Further reading.

By investigating the five research questions in Fig. 6, weaim to gain a broad picture of what the literature is report-ing on motivation in Software Engineering. We collectedinformation on Software Engineer characteristics (RQ1)to broaden our understanding of the underlying constructsrelating to what (de)motivates Software Engineers to bemore/less productive (RQ2). We then took a more in depthview of Software Engineer (de)motivators to uncover areasspecific to the Software Engineering task itself (RQ4). Tosee how motivation is measured and the potential benefitsor otherwise of motivating Software Engineers, weresearched the external signs of (de)motivated SoftwareEngineers. Finally, we looked at how all aspects of motiva-tion are modelled in the Software Engineering literature(RQ5).

4.1. Do Software Engineers form a distinct occupational

group?

Fig. 7 shows that papers fall into three categories whenconsidering whether Software Engineers form a distinctoccupational group.

Fig. 7 shows that 76% (54% + 22%) of papers find thatSoftware Engineers do form a distinct occupational group,albeit that in 22% of the cases this is context dependent.However, 24% of papers report that Software Engineersdo not form a distinct occupational group and in somecontexts this rises to 46% (24% + 22%). Six papers included

0

10

20

30

40

50

60

Global

Austra

lia

Austria

Canad

a

Egypt

Greece

Hong K

ong

Israe

lJa

pan

Mexico

Nigeria

Norway

China

Singap

ore

South

Africa

Taiwan UK

USA

Num

ber o

f stu

dies

Fig. 5. Countries represented in the empirical studies.

RQ3

What are the external signs of motivated SW Engineers and what are the external signs of de-motivated SW Engineers?

RQ1

What are the characteristics of Software (SW) Engineers?

SW Engineer motivators

and de-motivators

Outcomes of motivated

and de -motivatedSW Engineers

RQ5

What Models of Motivation exist in Software Engineering?

RQ2

What motivates and what de-motivates SW Engineers to be more/less productive?

RQ4What aspects of SW Engineering motivate and what aspects de-

motivate SW Engineers?

Fig. 6. The relationship between our five Research Questions.

YES54%

NO24%

YES&NO (dependingon context)

22%

Fig. 7. Do Software Engineers form a distinct group?


in our software characteristics group of papers do notcover this question and are therefore excluded from thisanalysis.

The following sub-sections look at each of our researchquestions in more detail.

4.2. RQ1 – Software Engineer characteristics

Forty-three papers were identified as answeringResearch Question 1 (RQ1), ‘‘What are the characteristics

of Software Engineers?’’These 43 papers identify 24 attributes which relate to

‘characteristics’ of SEs. However a closer inspection showsthat these attributes can be structured into three linked cat-egories. The first category contains the ‘raw’ characteristicsof Software Engineers. The second contains factors thatcontrol whether or not a particular individual will havethose characteristics. The third contains moderators whichdetermine the strength of a characteristic within an individ-ual. Fig. 8 shows how Characteristics, Control Factors andModerators seem to relate to one another: an individualwill have a given Characteristic (e.g. need for stability)

depending on their Control Factors (e.g. their Myers BriggsType Index (MBTI) score), and the strength of this charac-teristic is Moderated by contextual factors, such as thecountry they live and work in. This structure implies a dif-ferent profile of characteristics for every individual Soft-ware Engineer, and that over time, an individual’smotivation changes. Both of these implications are consis-tent with findings in the literature.

Control Factors

Personality factorsManagerial/technical leaningsInnate ability

Moderators

DemographicsExternal factors

Characteristics

Software Engineer Characteristics(16 identified)

Moderatesstrengthofeach

characteristic

Determines which

characteristicsanindividualhas

Fig. 8. Determinants of software engineer characteristics.


Using this structure, we have identified 16 ‘raw’ Soft-ware Engineer characteristics of which growth oriented,introverted and need for independence are the most cited.The literature often uses the term ‘Career Anchor’ todescribe a person’s characteristics. A person’s careeranchor is (1) his or her self concept of talents and abilities;(2) his or her self concept of basic values; and (3) the indi-vidual’s evolved sense of motives and needs [40].

Table 5 presents our literature review results forcharacteristics.

Control Factors relate to an individual’s personality,their internal make-up and their strengths and weaknesses.

Table 5Software Engineer characteristics

Ch: Software Engineer characteristics

Ch. 1 Need for stability (organisational stability)Ch. 2 Technically competentCh. 3 Achievement orientated (e.g. seeks promotion)Ch. 4 Growth orientated (e.g. challenge, learn new skills)Ch. 5 Need for competent supervising (e.g. needs respect and appreciationCh. 6 Introverted (low need for social interaction)Ch. 7 Need for involvement in personal goal settingCh. 8 Need for feedback (needs recognition)Ch. 9 Need for Geographic stabilityCh. 10 Need to make a contribution (needs worthwhile/ meaningful job)Ch. 11 Autonomous (need for independence)Ch. 12 Need for varietyCh. 13 MarketableCh. 14 Need for challengeCh. 15 CreativeCh. 16 Need to be sociable/identify with group/organisation/supportive rel

Table 6Software Engineer controllers

Con: Controllers

Con. 1 Personality traits (e.g. introverted, thinking)Con. 2 Career paths (managerial/technical)Con. 3 Competencies (how good they are at their job)

These control factors seem to determine the existence ofvarious ‘raw’ characteristics.

Table 6 presents our literature review results for controlfactors.

Table 6 shows there are many studies that report person-ality traits of Software Engineers. Our findings suggest thatan engineer’s personality, career path preference and com-petencies will control whether each of the 16 characteristicslisted in Table 5 form part of his or her make-up.

Moderators are external factors that influence charac-teristics, for example, environmental conditions, type ofwork and role are moderators. Our findings suggest thatmoderators change the strength of a particular SoftwareEngineer characteristic. Table 7 presents our results formoderators.

Finally, Table 7 shows that career stage and culture areoften cited in the literature as moderating an engineer’scharacteristics. To a lesser extent the literature considersthat the type of job and the type of organisation will alsomoderate an engineer’s characteristics. This means thatthese factors are likely to moderate the strength of eachcharacteristic an individual software engineer has.

4.3. Research Question 2

Sixty-two papers answered Research Question 2, ‘‘What

(de)motivates Software Engineers to be more (less)

productive?’’

Paper references Frequency(# of studies)

[1–5] 5[1,3,6–8] 5[2,9–11] 4[4,7,9,12–17] 9

, given a clear job to do and goals) [2,3,8,18] 4[12–14,19–22] 7[14] 1[14,15] 2[3] 1[3,4,8] 3[3–5,11,13,17,22] 7[3,5,17,23] 4[5,17] 2[5,11,17,20] 4[17,24] 2

ationships [4,8,9,17,25] 5

Paper references Frequency (# of studies)

[6,10,19,24,26–28] 7[3,4,29] 3[6,11,30,31] 4

Table 7Software Engineer moderators

Mod: Moderators (context) Paper references Frequency (# of studies)

Mod. 1 Career stage (age and experience, e.g. apprentice, colleague, mentor, sponsor) [6,26,32–37] 8Mod. 2 Culture (relating to different countries) [2,5,9,13,15,20,25,38] 8Mod. 3 Job type/role/occupational level [16,20,39,40] 4Mod. 4 State of IT profession (a snap shot of an evolutionary process) [22,37,39,41,42] 5Mod. 5 Type of organisation (e.g. promotion opportunities/rules) – relating to lifestyle [4] 1


This section is divided into papers that identify Motiva-tors; De-motivators; and Implementation Factors. Imple-mentation factors are issues that need to be consideredwhen applying motivators and influence the effectivenessof motivators. Table 8 summarises the frequencies ofpapers relating to motivators.

Table 8 shows that the most frequently cited motivatorsin the literature are, ‘the need to identify with the task’ suchas having clear goals, a personal interest, understanding thepurpose of task, how the task fits in with the whole, havingjob satisfaction; and working on an identifiable piece ofquality work. Having a clear career path and a variety oftasks is also found motivating in several papers.

Table 8RQ2 – motivators in Software Engineering

Motivators

M. 1 Rewards and incentives (e.g. scope for increased pay and benefitslinked to performance)

M. 2 Development needs addressed (e.g. training opportunities to widenskills; opportunity to specialise)

M. 3 Variety of work (e.g. making good use of skills, being stretched)M. 4 Career path (opportunity for advancement, promotion

prospect, career planning)M. 5 Empowerment/responsibility (where responsibility is assigned to the

person not the task)M. 6 Good management (senior management support, team-building, good

communication)M. 7 Sense of belonging/supportive relationshipsM. 8 Work/life balance (flexibility in work times, caring manager/employer,

work location)M. 9 Working in successful company (e.g. financially stable)M. 10 Employee participation/involvement/working with othersM. 11 FeedbackM. 12 Recognition (for a high quality, good job done based on objective

criteria – different to M1 which is about making sure that there arerewards available)

M. 13 EquityM. 14 Trust/respectM. 15 Technically challenging workM. 16 Job security/stable environmentM. 17 Identify with the task (clear goals, personal interest, know purpose

of task, how it fits in with whole, job satisfaction; producing identifiablepiece of quality work)

M. 18 Autonomy (e.g. freedom to carry out tasks, allowing roles to evolve)M. 19 Appropriate working conditions/environment/good equipment/

tools/physical space/quietM. 20 Making a contribution/task significance (degree to which

the job has a substantial impact on the lives or work of other people)M. 21 Sufficient resources

Table 9 lists the de-motivators found in theliterature.

Table 9 shows that poor working conditions and lack ofresources are reported as de-motivating in nine separatestudies.

The literature reports that to implement the motivatorsnoted in Table 8, factors listed in Table 10 need to be con-sidered. How the job-fits with an individual’s needs is con-sidered important in nine separate studies. Here,motivation is viewed as a function of the ‘fit’ between theindividual and the organisational job setting. The conceptof ‘job-fit’ is detailed in the work of social scientist McClel-land in [33].

References Frequency(# ofstudies)

[7,23,36,43–53] 14

[3,7,22,25,43,44,48,49,54–56] 11

[9–11,25,29,37,43,44,48,50–52,55,57] 14[3,9,11,25,29,37,43,44,47,48,50–52,55,57] 15

[7,11,44,54,57,58] 6

[7,10,18,22,25,37,44,46,48,49,51,53,54,56,59,60] 16

[8,10,21,22,25,43–45,49,56,61–64] 14[4,25,43–45,64,65] 7

[4,44] 2[23,33,43,44,49,52,54,58,60,66,67,10,25,49,63,68] 16[9,10,20,23,33,37,45,56,67,69] 10[7,8,10,22,23,25,46,48,49,51,54,68] 12

[52,67,70] 3[8,33,58,70] 4[11,22,42,46,48,54,59,64,65,67,68] 11[23,25,43,46–48,50,56,59,71] 10[7–9,11,18,20,22,23,33,47–51,53,54,56,67,68,72] 20

[7,9–11,33,56,67–69] 9[4,7,47,64,67,73] 6

[8,9,11,33,48,61] 6

[25,48] 2

Table 9RQ2 – de-motivators in Software Engineering

De-motivators References Frequency(# of studies)

D. 1 Risk [1] 1D. 2 Stress [43,66,69,74,75] 5D. 3 Inequity (e.g. recognition based on management intuition or personal preference) [7,43,56,66] 4D. 4 Interesting work going to other parties (e.g. outsourcing) [45] 1D. 5 Unfair reward system (e.g. management rewarded for organisational performance; company

benefits based on company rank not merit)[7,70] 2

D. 6 Lack of promotion opportunities/stagnation/career plateau/boring work/poor job-fit [37,56,61,76,77] 5D. 7 Poor communication (feedback deficiency/loss of direct contact with all levels of management) [7,13,20,39,56] 5D. 8 Uncompetitive pay/poor pay/unpaid overtime [7,13,20,56,77,78] 6D. 9 Unrealistic goals/phoney deadlines [7,13,23,42,56,77] 4D. 10 Bad relationship with users and colleagues [42,51,56,74] 4D. 11 Poor working environment (e.g. wrong staffing levels/unstable/insecure/lacking in investment

and resources; being physically separated from team)[4,7,10,22,23,56,73,74,79] 9

D. 12 Poor management (e.g. poorly conducted meetings that are a waste of time) [7,20,22,23,42,47,56,79] 7D. 13 Producing poor quality software (no sense of accomplishment) [7,23,56] 3D. 14 Poor cultural fit/stereotyping/role ambiguity [42,51,63] 3D. 15 Lack of influence/not involved in decision making/no voice [23,56] 2



Eighteen papers were identified as answering ResearchQuestion 3, ‘‘RQ3: What are the external signs or outcomesof (de)motivated Software Engineers?’’

Table 11 lists the external signs associated with moti-vated or de-motivated software engineers, as identified inthese 18 papers.

The majority of the studies cited retention as the majoroutcome of motivated or de-motivated software engineers.Twelve studies showed that motivated engineers tend tostay in their jobs longer than de-motivated engineers. Fivestudies reported that productivity is affected by motivated/de-motivated engineers.


Eighteen papers answered Research Question 4, ‘‘Whataspects of Software Engineering (de)motivate SoftwareEngineers?’’

Table 12 identifies themes based on (de)motivators relat-ing to the Software Engineering activity itself. Factorsrelated to salary or other motivators extraneous to Soft-ware Engineering itself have not been included in this anal-ysis. This question is an offshoot of our Research Question

Table 10RQ2 – implementation factors

Implementation factors References Frequency(# of studies)

IMP 1: Job-fit [12,13,15,22,37,38,63,75,80] 9IMP 2: Tailoring practices [11,43,59,62,71,75] 6IMP 3: Long term/short

term strategies[43] 1

IMP 4: Temporal effects [1,42,56,72,78,81] 6IMP 5: Individual differences [5,29,55,56,67] 5

2 that takes a more general view of all motivators found inSoftware Engineering.

We found comparatively few studies that identified spe-cific tasks that motivate software engineers. A key study inthis area is Almstrum [83], who asked the question ‘‘Whatis the attraction to Computing? We have built on some ofthe themes identified by Almstrum such as benefit, scienceand experiment.

Table 12.1 shows that only two studies considered whataspects of the lifecycle de-motivated software engineers,both identified the maintenance task.

Similar to our findings relating to Research Question 2;Table 12.2 highlights that five studies found that the degreethat an engineer finds aspects of the Software Engineeringjob motivating on de-motivating will depend on his or herpersonal job-fit.


Seventeen papers were identified as answering ResearchQuestion 5, ‘‘What models of motivation exist in Software

Engineering?’’We searched for models that try to explain how motiva-

tion works or why motivation works the way it does. A

Table 11External signs of motivated and de-motivated software engineers

External signs References Frequency(# of studies)

Ext 1: Retention [21,25,32,38,43,45,50,52,57,62,66,81]

12

Ext 2: Project delivery time [16,82] 2Ext 3: Productivity [6,21,58,68,73] 5Ext 4: Budgets [81] 1Ext 5: Absenteeism [50] 1Ext 6: Project success [68] 1

Table 12Aspects of Software Engineering that motivate Software Engineers

Motivating aspects of Software Engineering field References # of studies

Asp 1: Problem solving (the process of understanding and solving a problem in programming terms) [10,22,83] 3Asp 2: Team working [61,84] 2Asp 3: Change [2,11,42,85] 4Asp 4: Challenge (Software Engineering is a challenging profession and that in itself is motivating) [22,42,61,65] 4Asp 5: Benefit (creating something to benefit others or enhances well-being) [10,61,83] 3Asp 6: Science (making observations, identifying, describing, engineering, investigating and theorising, explaining a

phenomena)[77,83] 2

Asp 7: Experiment (trying something new, experimentation to gain experience) [55,83] 2Asp 8: Development practices (Object Oriented, XP and prototyping practices) [85,86] 2Asp 9: lifecycle – software development, project initiation and feasibility studies, *maintenance

(*also found a de-motivating activity)[77] 1


breakdown of the themes we identified in the literature ispresented in Table 13.

The literature presents a disparate set of models that aremostly hypothesised from theoretical studies and validatedthrough empirical surveys. A commonly cited model ofmotivation is the Job Characteristics Theory (JCT) Model[26]. The basic tenet of the JCT is that Software Engineerswill experience internal motivation and satisfaction if theirGrowth Need Strength’s (GNS) are matched by the Moti-vational Potential Score (MPS) of the jobs they do. Thisimplies that Software Engineers with low GNS will be sat-

Table 12.1De-motivating aspects of Software Engineering

References # of studies

De-asp 1: Software process/lifecycle –maintenance (note that maintenancewas also found motivating under someconditions)

[12,85] 2

Table 12.2Implementation factors (as in Table 10)

References # of studies

Imp 1: Job-fit [15,20,37,82,85] 5

Table 13Models of motivation in Software Engineering

Explicit models of motivation

Mod 1: Job Characteristics Theory Model (JCT) of Software Engineer(SE) motivation (development, enhancement or validation)

Mod 2: Models of leadership influence on SE motivationMod 3: Models of open source developer SE MotivationMod 4: Model of task design influence on SE motivationMod 5: Model of career progression influence SE on motivation

Implicit Models of motivation

Rel 1: Models focussing on Software Engineer job satisfactionRel 2: Model drawing on expectancy theory, goal-setting theory, and

organizational behaviour specific to the software development processRel 3: Social support influence on Software Engineer turnover

isfied with low MPS in a job, in much the same way asthose with high GNS will need high MPS in a job. Opti-mum internal motivation and satisfaction is achieved whenSoftware Engineers’ GNS’s are matched with the appropri-ate MPS’s in a job.

Five papers in our review explicitly build upon the JCTto extend it (e.g. with role ambiguity/conflict and leader-ship styles), validate it using comparisons with countriesoutside the USA, such as Japan, or enhance it, e.g. lookingat employment fit (which is similar to job-fit, but includesworking conditions). A further five papers presented mod-els that focus on job satisfaction, which is an element of theJCT and is therefore linked to motivation. For example,Santana and Robey [56] suggest that managerial, teammember or self-control of tasks influences the level of jobsatisfaction felt by an employee.

Three papers explicitly investigate the motivation ofopen source developers. Hertel et al. [87] considers whethertwo social science models (one focusing on voluntaryaction and one focusing on small teams) adequately explainOSS developers’ motivation. Li et al. [59] focuses on lead-ership styles, and Roberts et al. [88] investigates the rela-tionship between intrinsic, extrinsic and internalisedextrinsic motivators.

Two papers focus on job or employment fit of somekind. For example, [89] focuses on validating an instrument

References Frequency (# of studies)

[14,15,89–91] 5

[7,59,91] 3[59,87,88] 3[67] 1[60] 1

[50,52,53,56,62] 5[92] 1

[62] 1


to measure employment arrangement fit. This reflects find-ings from other literature identified under RQ1 where theinfluence of career anchor is highlighted. In addition,RQ4 identifies job-fit as being a (de)motivator for SEs.

5. Discussion

In this section, we discuss how the literature in our sys-tematic literature review assists us to understand the under-lying constructs of motivation in Software Engineering.Fig. 9 shows our enhanced understanding of our researchtopics introduced in Fig. 6.

5.1. Software engineers as a homogeneous occupational

group

Fig. 9 shows that the literature is divided as to whetherSoftware Engineers form a distinct occupational group.However, the majority of included studies support the ideathat these practitioners do form a recognisable group withsimilar needs. This view is consolidated in the manystudies from Couger, Zawacki and colleagues, e.g.[17,9,20,16,8,10,11,13,14,5,12,15] based on a comparisonof job perceptions and needs of more than 6000 peoplefrom both Software Engineers [Data Processors/IT profes-sionals] and the general public. These studies reported thatSoftware Engineers found their work less meaningful andrated their jobs less favourably than other professionals.Their need to interact with others was negligible. SoftwareEngineers displayed very high growth needs and were con-cerned about learning new technology. Myers [36] refinedthe studies of Couger and Zawacki and colleagues to showthat although Software Engineers formed a distinct group,they varied among themselves by job type. More recent

Key ResultsRQ1: What are the characteristics of Software Engineers? RQ2: What (de)motivates Software Engineers to be more

(less) productive? RQ3: What are the external signs or outcomes of

(de)motivated Software Engineers? RQ4: What aspects of Software Engineering (de)motivate

Software Engineers? RQ5: What models of motivation exist in Software

Engineering?

Table Table8

Table

Table

Table

RQ5Models in SW Engineering that capture some

RQ1Individual personality

Context (e.g. job type/

culture)

+/- SW Engineer Characteristics

Not distinct group

A distinct group

controls

moderates

Fig. 9. Model of motivation in Software Engineering. See

work that presents Software Engineers as a distinct groupinclude: [29,6,24,43,18,39].

However, several studies take a contrary view. Forexample, Ferratt and Short [22,23] found that SoftwareEngineering employees and non-Software EngineeringEmployees [IS and non-IS employees] could be motivatedequally using the same underlying constructs. Im and Hart-man [28] although disputing Ferratt and Short’s [22] meth-odology, supported their outcome. More recent work thatpresents Software Engineers as a group that cannot be dis-tinguished from other occupations when considering moti-vation include [21,41].

These mixed findings from the 1980s to today lead us toconclude that whether or not software engineers form ahomogeneous group with similar motivational needsdepends on their individual context.

5.2. RQ1 – Software Engineer characteristics

The 43 papers that cover this question provide us with abroad picture of Software Engineer characteristics. As thesecharacteristics are based on studies from different countries,practitioner roles, personality types, organisations, devel-opment processes and historical periods, we cannot assumethat every characteristic relates to all software engineers. Infact is it clear that this would not be feasible, since some ofthe characteristics contradict each other. For example, engi-neers are seen to be sociable yet introverted, needing stabil-ity on the one hand and liking a variety of new tasks andchallenges on the other. Therefore, to apply these character-istics to any individual we have extracted implicit findingsfrom the papers and identified two new categories: ‘moder-ators’ (environmental and demographic influences) andcontrollers (internal constructs).

Definitions 5-7 -10

11

12

13

Extrinsic factors: External to the job practitioners do,e.g. work conditions. These factors just maintainpractitioners in their jobs [1] Intrinsic factors: Primary determinant of motivation and satisfaction. Related to Job itself, e.g. work itself, recognition, achievement [1]Personality: more or less permanent characteristics of an individual's state of being, (e.g. shy, extrovert, conscientious) [7].

aspect of motivation

RQ2General Motivators

(extrinsic and intrinsic) in SW Engineering

Literature

RQ4 Motivators/Job

satisfiers specific to SW Engineering

(activity)

RQ3Outcome (include

more/less absenteeism,

retention, increased/

decreased quality)

above-mentioned references for further information.


We do not report on the cognitive aspects of a SoftwareEngineer’s personality which go beyond the scope of thisstudy. However, we note that cognitive processes and per-sonality traits need to be considered and understood asthese internal constructs will determine an individual’s setof characteristics. As Chelsom et al. [7] note, the differencesin people’s personality are greater than the similarities, and‘‘we cannot ignore the significance of individuality’’. Theliterature also shows that external factors such as careerstage and culture need to be considered as these will ‘mod-erate’ the strength of each characteristic.

The characteristics cited most often in the literature arethe need for growth and independence. The need for growthmay be due to the engineer’s internal make-up, and/or theneed be ‘marketable’ (another characteristic) and keep upwith the fast changing technology. The need for indepen-dence is possibly linked to the type of person attracted toSoftware Engineering that is sometimes seen as a creativetask that is not helped by overbearing management.

Many of the characteristics we identify reflect the findingsand views of Couger and Zawacki [9]. This is not surprisingas their job diagnostics survey for data processing personnel(JDS/DP) has been used in several of the papers included inour literature review, e.g. [16,8,10,13,11,14,12,15].

We have extracted from the literature a more structuredview of the findings concerning SEs characteristics, notingthat the characteristics of any one individual depend oncontrollers, such as personality trait and moderators suchas career stage.

5.3. RQ2 – what motivates Software Engineers?

The 62 papers that answer this question create a list of21 different motivators. The most frequently cited motiva-tors in the literature are, ‘the need to identify with the task’such as having clear goals, a personal interest, understand-ing the purpose of a task, how it fits in with the whole, hav-ing job satisfaction; and working on an identifiable piece ofquality work. Having a clear career path and a variety oftasks is also found motivating in several papers. The liter-ature suggests it is important to involve the engineer indecision making, and to participate and work with others,which appears to go against characteristics of indepen-dence and introversion which are cited in many papers.When looking at what Software Engineering activitiesmotivate Software Engineers we need to consider that someof the findings might not apply today. For example, wehave listed Object Oriented Design as a motivator that isreported as meeting a growth need in engineers. However,as this finding was reported in the 1990s, it may be that thisfulfilled a growth need only because Object OrientedDesign was a new skill at the time – this may no longerapply today. This is just one example of how a motivatormay be context specific, relating to time, role, culture, expe-rience, age, individual characteristic etc.

An aspect of Software Engineering found both motivat-ing and de-motivating is the maintenance task. This could

be due to several factors. For example this evolutionaryphase of software development can consume between 40%and 80% of software costs. If it is the dominant activitywithin a group, then it may attract the recognition and chal-lenges associated with motivation. Alternatively, as approx-imately 60% of maintenance tasks are in fact enhancements[25] this might also be regarded as problem solving and chal-lenging. Finally, bug-fixing may be regarded as motivating ifthe right person is given the job, i.e. the job-fit is right.

5.3.1. Software Engineer de-motivators

To give a balanced view, we also recorded what the lit-erature reports on Software Engineer de-motivators.Working conditions and lack of resources are reported asde-motivating in nine separate studies. These are classedas hygiene factors by Herzberg and Mausner [27], whodeveloped the hygiene-motivator theory in the 1950s. Thistheory asserts that removing the de-motivator will not nec-essarily translate to motivating employees. It will simplymaintain practitioners in their job and avoid dissatisfac-tion. Salary or rewards are an exception to this rule; a goodsalary can be motivating in unstable environments andearly in an engineer’s career, although salary is usually con-sidered a hygiene factor.

5.3.2. Motivating and de-motivating factors

Finding a factor to be both motivating and de-motivat-ing might be due the temporal effects of motivation as high-lighted by Maslow’s (1954) [32] hierarchy of needs theory.What might motivate someone in the early stages of theircareer may end up de-motivating them in the latter stagesof their career. For example, the newly recruited SoftwareEngineer could be highly motivated by job security andclose supervision, whereas these same factors, especiallyclose supervision, could turn out to be de-motivating to aseasoned Software Engineer. An experienced SoftwareEngineer is more likely to be motivated by challenges,opportunities for recognition and autonomy.

5.4. RQ3 – the outcomes of motivating software engineers

Considering the large body of work on motivation, verylittle work covers the tangible benefits or outcomes of moti-vating engineers. Eighteen studies were found in this cate-gory (RQ3), where most dealt with turnover andabsenteeism. Turnover and absenteeism focus on the likeli-hood of an individual staying in a particular job. As mea-sures of motivation therefore they suffer from being amanagement and organisational view of motivation, i.e.they consider motivation from an organisation’s perspec-tive. We found little work that focused on understandingor measuring an individual’s motivation to stay in SoftwareEngineering as a profession.

Also, very few studies considered productivity improve-ments or increase in quality. This is possibly due to the dif-ficulty in measuring motivation and associating motivationwith actual output. Also the themes of turnover and absen-


teeism are part of the JDS/DP [9] – a survey used by manyof the studies included in this review.

5.5. RQ4 – what is motivating about Software Engineering

Although this review takes in a large range of studiesrelating to Software Engineering, only a very small propor-tion identify what is specifically motivating about this field.When looking at answers to RQ2 (Table 8) for instance,most of the motivators could apply to many professions.

The literature identifies Software Engineering as a chal-lenging profession and often links challenge to change, asnoted in [83] ‘‘the reason for challenge is the pace of changeof the field and the effort it took to keep pace with thechanges. . . .If you just want to learn something and do itfor the rest of your life. . .. you do not want to go intoIT’’. Challenge also relates to ‘technical’ challenges (notjust coping with change).

Learning, exploring new techniques and problem solv-ing would also appear to be motivating tasks,. ‘Benefit’ isa category identified by Almstrum [83] and is supportedin the work of [83,88,59], where the three different studiesshow Software Engineers are motivated by ‘‘creating some-thing that will benefit others’’; ‘‘the usefulness in support-ing other areas/fields’’; and creating something that is ‘‘ofvalue to the user’’.

As observed above, we found little work that explicitlyfocused on Software Engineering as a profession, andhence considering why Software Engineers remain in Soft-ware Engineering (even if they change jobs).

5.6. RQ5 – modelling motivation in Software Engineering

We aimed to synthesise the findings on how motivationin software engineering is modelled in the literature. How-ever, we found it very difficult to combine all the models asthey tend to cover general aspects of motivation, have fewcommonalities and only partially cover the Software Engi-neering domain. exception to this is found in the recurringtheme of models based on the Job Characteristics Theory(JCT) (Hackman and Oldman, 1976) and the JDS/DP [9].

The results from RQ5 though difficult to assimilate fallinto one of three camps: those that use and adapt theJCT model and the JDS/DP e.g. to add leadership consid-erations, those that try to provide an alternative to the JCTapproach, and those that take a totally different approach(e.g. using small-team theories to explain Open SourceDevelopment).

According to Couger and Zawacki [9], the JCT (Hack-man and Oldman, 1976) was found useful for manage-ment in Software Engineering to analyse individualpatterns of motivation. Couger and Zawacki augmentedthe underlying constructs of this model in the Job Diag-nostics Survey for Data Processing Personal (JDS/DP) toprovide a richer picture of how growth need strength(GNS) relates to Motivation Potential Score (MPS) in agiven job.

Literature that uses the JDS/DP generally aims to vali-date the theory in different national cultural contexts andoften uses the USA as the benchmark. It is helpful forcross-comparisons to use the same instrument with otherprofessions and between and within given roles, showingthe strength of feeling for certain needs and identifying dif-ferences and similarities. However, the JDS/DP comprisesa tick list of factors, and so studies based on the JDS/DPwill only be able to comment on motivating factors con-tained within the instrument rather than unearth any newmotivators or emerging trends. The nature of the SoftwareEngineer’s job has changed considerably since the JDS/DPwas first devised, and so it is questionable as to whether ornot it is as applicable as it used to be.

We have not found a definitive model of motivation inSoftware Engineering that adequately captures the motiva-tors and de-motivators we found in answer to RQ4, ‘‘What

aspects of Software Engineering (de)motivate Software

Engineers?’’, nor the other facets of Software Engineercharacteristics and motivation reported through RQs1–3.

6. Limitations

6.1. Completeness

We have conducted a very thorough review of the litera-ture eliciting work from 70 different authors including somesecondary studies (where we used the reference in the pri-mary study to lead to another study). We note however thatwith the increasing number of works in this area we cannotguarantee to have captured all the material in this area.

Another area of concern is that few studies have beenpublished on motivation in Software Engineering in coun-tries such as India that are increasingly involved in Soft-ware Engineering [45], suggesting that we cannot presenta global view of this area. This is not a limitation of ourapproach, but a reflection of the limitations imposed onus by the available research in this area.

6.2. Potential Bias

The studies included in this review have undergone athorough selection process that involved several research-ers cross-checking the completeness of searches and vali-dating the suitability of each study for inclusion.However, as there is a systematic bias in the way theresearch is conducted in many of the included studies(often based on convenience samples) we note that ourresults may not be representative of the population of Soft-ware Engineers. Also, as the studies emanate mainly fromwork carried out in the West, we cannot generalize ourresults.

6.3. Data synthesis

Different countries, eras in Software Engineering andSoftware Engineer roles have been grouped together in


order to identify themes that answer our research ques-tions. However, there is a suggestion in some of the litera-ture that different roles are associated with differentmotivational needs and characteristics. By grouping allroles together, we may have lost some of this detail. In thisreview the term ‘Software Engineer’ encapsulates a multi-tude of roles in software engineering as we include all prac-titioners who are directly involved in producing software.We were necessarily guided by the literature in this respectwhich rarely defined or differentiated individual practi-tioner roles, but we are also aware that job titles andresponsibilities have changed over the time period coveredby the review, e.g. in the mid 1980s the job title ‘program-mer/analyst’ was common, whereas by the early 1990s peo-ple were referred to as ‘software engineers’. We do notdiscuss the many, changing and expanding roles in Soft-ware Engineering here as this goes beyond the scope of thispaper.

We may also have lost some of the detail of changesover time by grouping all papers together by theme andignoring the date of publication in the rage of 1980–2006. For example, it could be that the changing profileof SE has affected motivational factors; however the num-ber of papers published from the year 2000 onwards (39)represent a large portion (42%) of the overall 92 papers.So we have a sample of papers that are more representa-tive of current trends than those in say 1980’s (thatinclude 19 papers (or 20%) for the whole decade). Whenwe aggregate our themes the reported frequencies needto be treated with caution.

7. Further research

This review has raised many questions that would bene-fit from further research. For example, whether SoftwareEngineers form a distinct occupational group remains lar-gely unresolved, and is a subject in need of further study.It would also be useful to look at how motivational factorslink to an individual’s specific career stage or specific role,and whether motivational factors change over time, e.g. dothe findings of studies conducted in the 1980s reflect thestudies conducted more recently? In addition, further workis needed to develop a definitive model of motivation insoftware engineering.

8. Conclusions

Our findings suggest an increasing awareness of moti-vation in Software Engineering since about 1995, as com-pared to the previous 15 years. Most of the studies inthis area rely on the use of questionnaires, with 16%using multiple data collection methods and only 1%using multiple methods without questionnaire. Over halfof the studies (54) were conducted in the USA. In addi-tion, the majority of papers were published in the Pro-ceedings of SIGCPR Computer Personnel Researchrather than mainstream Software Engineering conferences

or journals. Notwithstanding this, the 92 papers in oursystematic literature review provide a broad understand-ing of the research conducted into what has motivatedSoftware Engineers in 16 different countries over the past26 years.

Mixed findings in the literature lead us to concludethat whether software engineers form a homogeneousgroup with similar needs depends on their individual con-text. Building on the work reported, we have structuredthe SE characteristics investigated in the literature intothree related categories: ‘raw’ characteristics, moderatorsand controllers. Whether or not an individual has a par-ticular characteristic depends on certain controllers, andhow strong this characteristic is depends on themoderators.

The literature cites 21 different motivators for SoftwareEngineers. The most frequently cited ones are, ‘the need toidentify with the task’ such as having clear goals, a per-sonal interest, understanding the purpose of a task, howit fits in with the whole, having job satisfaction; and work-ing on an identifiable piece of quality work. However somefactors are identified as being both motivators and de-moti-vators. It may be possible to account for this by consider-ing the career stage of the individual.

Turnover and absenteeism are the most cited outcomesof (de)motivated engineers (may be because these are men-tioned in the JDS/DP). We found little work that focusedon understanding or measuring an individual’s motivationto stay in Software Engineering as a profession.

Learning, exploring new techniques and problem solv-ing appear to be motivating aspects of SE. However littlework has focused on the specific nature of Software Engi-neering itself, or of the impact of the changing environmentin which Software Engineering is conducted.

Although we found a variety of models of motivation inSoftware Engineering in the literature, no model consid-ered all the identified factors in our list of motivators, mod-erators, controllers and implementers. Neither did any ofthe models focus on the nature of the SE’s job itself suchas the reliance on tools or programming languages, the log-ical nature of problem solving, use of creativity, complexproblem solving, and so on. Yet ‘the job itself’ continuesto be the principal motivator. Therefore, considering thechanges in what the job demands, in terms of new skillsand communicating with many different stakeholders, thereappears to be a gap in defining what exactly it is about ‘thejob’ that motivates engineers.

It is clear from the literature that there is a need for acomprehensive model of motivation in Software Engineer-ing that includes what is particularly motivating about thejob itself. We also need a better way to measure motiva-tion, as basing it on turnover only reflects whether an engi-neer is motivated to stay in an organisation. It does notshed light on what motivates an individual to stay in theSE profession, to produce better quality software, increaseproductivity, and use and share skills in the wider SoftwareEngineering community.


Acknowledgments

We thank Dorota Jagielska for helping us pilot thisstudy and David Clover of The Open University for settingup a collaborative website for the project group. This re-search was supported by the UK’s Engineering and Physi-cal Science Research Council, under Grant No. EPSRCEP/D057272/1.

References

[1] N. Baddoo, T. Hall, Motivators of software process improvement: ananalysis of practitioners’ views, Journal of Systems and Software 62(2) (2002) 85–96, Elsevier Science Inc.

[2] K.M. Bartol, D.C. Martin, Managing information systems personnel:a review of the literature and managerial implications, MIS Quarterly6 (Special Issue) (1982) 49–70.

[3] S. Beecham, N. Baddoo, et al., Protocol of a Systematic LiteratureReview of Motivation in Software Engineering, Technical Report No.452 School of Computer Science, Faculty of Engineering andInformation Sciences, University of Hertfordshire, 2006.

[4] B.W. Boehm, Engineering Economics, Prentice-Hall, Inc., EnglewoodCliffs, 1981.

[5] J.M. Burn, J.D. Couger, et al., Motivating IT professionals. TheHong Kong challenge, Information & Management 22 (5) (1992)269–280.

[6] L.F. Capretz, Personality types in software engineering, InternationalJournal of Human Computer Studies 58 (2) (2003) 207–214.Academic Press.

[7] J.V. Chelsom, A.C. Payne, and L.R.P. Reavill, Management forEngineers, Scientists and Technologists, second ed., 2005.

[8] D.J. Couger, S.C. Mcintyre, Motivation norms of knowledgeengineers compared to those of software engineers, Journal ofManagement Information Systems 4 (3) (1987) 82–93.

[9] D.J. Couger, R.A. Zawacki, Motivating and Managing ComputerPersonnel, John Wiley & Sons, 1980.

[10] D.J. Couger, Motivators vs. demotivators in the IS environment,Journal of Systems Management 39 (6) (1988) 36–41.

[11] J.D. Couger, Comparison of motivating environments for program-mer/analysts and programmers in the US, Israel and Singapore,System Sciences. Vol. IV: Emerging Technologies and ApplicationsTrack, in: Proceedings of the Twenty-Second Annual Hawaii Inter-national Conference on 4, 1989, pp. 316–323.

[12] J.D. Couger, Comparison of motivation norms for programmer/analysts in the Pacific Rim and the U.S., International Journal ofInformation Systems 1 (3) (1992) 16–30.

[13] J.D. Couger, H. Adelsberger, Environments: Austria compared to theUnited States, SIGCPR Comput. Pers. 11 (4) (1988) 13–17. ACMPress.

[14] J.D. Couger, H. Adelsberger, et al., Commonalities in motivatingenvironments for programmer/analysts in Austria, Israel, Singapore,and the U.S.A, Information & Management 18 (1) (1990) 41–46.

[15] J.D. Couger, A. Ishikawa, Comparing motivation of Japanesecomputer personnel versus these of the United States, SystemSciences, vol. IV, in: Proceedings of the Twenty-Eighth HawaiiInternational Conference on 4, 1995, pp. 1012–1019.

[16] J.D. Couger, S.C. McIntyre, Motivating norms for artifical intelli-gence personnel, in: Proceedings of the Twentieth Hawaii Interna-tional Conference on System Sciences. Hawaii Int. Conf. Syst. Sci., 4(1987) 370.

[17] J.D. Couger, R.A. Zawacki, What motivates DP professionals?Datamation 24 (9) (1978) 116.

[18] D.P. Darcy, M. Ma, Exploring Individual Characteristics andProgramming Performance: Implications for Programmer Selection,International Conference on System Sciences, in: HICSS’05, Pro-

ceedings of the 38th Annual Hawaii (03–06 January), University ofMaryland, College Park, 2005, pp. 314a–314a.

[19] T. Demarco, T. Lister, Peopleware – Productive Projects And Teams,Dorset House, 1999.

[20] J.E. Dittrich, J. Daniel Couger, et al., Perceptions of equity, jobsatisfaction, and intention to quit among data processing personnel,Information & Management 9 (2) (1985) 67–75.

[21] H.G. Enns, T.W. Ferratt, et al., Beyond stereotypes of IT profes-sionals: implications for IT HR practices, Communications of theACM 49 (4) (2006) 106–109.

[22] T.W. Ferratt, L.E. Short, Are information systems people different:an investigation of motivational differences, Management Informa-tion Systems Quarterly 10 (4) (1986) 377–387.

[23] T.W. Ferratt, L.E. Short, Are information systems people different?An investigation of how they are and should be managed, Manage-ment Information Systems Quarterly 12 (3) (1988) 427–443.

[24] A.I. Garza, S.E. Lunce, et al., Career anchors of Hispanic informa-tion systems professionals, in: Proceedings – Annual Meeting of theDecision Sciences Institute, Decision Sciences Institute, 2003, pp.1067–1072.

[25] R. Glass, Facts and Fallacies of Software Engineering, Addison-Wesley, Boston, USA, 2003.

[26] J.R. Hackman, G.R. Oldman, Motivation through the design ofwork: Test of a Theory, Academic Press, New York, 1976.

[27] F. Herzberg, B. Mausner, et al., The Motivation to Work, seconded., Chapman & Hall, London, 1959.

[28] J.H. Im, S. Hartman, Rethinking the issue of whether IS people aredifferent from non-IS people, MIS Quarterly 14 (1) (1990) 1–2, JSTOR.

[29] H. Kandeel, K. Wahba, Competency models for human resourcedevelopment: case of Egyptian software industry. Managing Infor-mation Technology in a Global Environment. Information ResourcesManagement Association International Conference, 2001, pp. 117–121.

[30] B. Kitchenham, Procedures for Performing Systematic Reviews,Keele University and National ICT Australia Ltd, 2004, pp. 1–28.

[31] B. Kitchenham, E. Mendes, et al., A Systematic Review ofCross- vs. Within-Company Cost Estimation Studies, EASE 200610th International Conference on Evaluation and Assessment inSoftware Engineering: Keele University, Staffordshire, UK, 2006,pp. 89–98.

[32] A. Maslow, Motivation and Personality, Harper & Row, New York,1954.

[33] D.C. McClelland, Power: The Inner Experience, Irvington press, NewYork, 1975.

[34] S. McConnell, Problem programmers, Software, IEEE 15 (2) (1998)126–128, 127.

[35] MOMSE(CFS), Modelling motivation in software engineering Casefor Support. (EPSRC Proposal, EPSRC Reference: EP/D057272/1),2005.

[36] M.E. Myers, The information systems profession and the informationsystems professional – fit or misfit? in: A.L. Lederer (Ed.), Proceed-ings of the 1992 ACM SIGCPR conference on computer personnelresearch Cincinnati, Ohio, 1992, 350–351.

[37] J.D. Procaccino, J.M. Verner, et al., What do software practitionersreally think about project success: an exploratory study, Journal ofSystems and Software 78 (2) (2005) 194–203, Elsevier Inc., New York,NY 10010, United States..

[38] ProjectLink, Motivation House. Available from: http://www.project-link.co.uk/whoweworkfor.htm, accessed 2006.

[39] S. Ramachandran, S.V. Rao, An effort towards identifying occupa-tional culture among information systems professionals, in: Proceed-ings of the 2006 ACM SIGMIS CPR conference on computerpersonnel research: Forty four years of computer personnel research:achievements, challenges & the future, ACM Press, Claremont,California, USA, 2006, pp. 198–204.

[40] E.H. Schein, Career anchors revisited: implications for careerdevelopment in the 21st century, Academy of Management Executive4 (10) (1996) 80–88.

http://www.projectlink.co.uk

http://www.projectlink.co.uk


[41] D.C. Smith, H.L. Speight, Antecedents of turnover intention andactual turnover among information systems personnel in SouthAfrica, in: Proceedings of the 2006 ACM SIGMIS CPR conference oncomputer personnel research: Forty four years of computer personnelresearch: achievements, challenges & the future, ACM Press,Germany, 2006, pp. 123–129.

[42] Standish Report, Standish Group Chaos Report from URL http://www.scs.carleton.ca/~beau/PM/Standish-Report.html, 1995.

[43] F.R. Tanner, On motivating engineers, Engineering ManagementConference, 2003. IEMC’03. Managing Technologically DrivenOrganizations, The Human Side of Innovation and Change (2003)214–218.

[44] J.L. Wynekoop, D.B. Walz, Revisiting the perennial Question: are ISPeople Different? The Database for Advances in Information Systems29 (2) (1998) 62–72.

[45] E. Yourdon, Outsource – Competing in the Global ProductivityRace, 2005.

Further reading

Numeric references for the 92 studies included in Sys-tematic Literature Review (Section 4).[1] R. Agarwal, P. De, T.W. Ferratt, Explaining an IT professional’s

preferred employment duration: Empirical tests of a causal model ofantecedents, Proceedings of the ACM SIGCPR Conference (2002)14–24.

[2] J.M. Burn, L.C. Ma, E.M. Ng Tye, Managing IT professionals in aglobal environment, SIGCPR Comput. Pers 16 (3) (1995) 11–19.

[3] R.G. Crepeau et al., Career Anchors of Information SystemsPersonnel, Journal of Management Information Systems 9 (2)(1992) 145–160.

[4] A.I. Garza, S.E. Lunce, B. Maniam, Career anchors of Hispanicinformation systems professionals, Proceedings – Annual Meeting ofthe Decision Sciences Institute (2003) 1067–1072.

[5] A. Ituma, The internal career: an explorative study of the careeranchors of information technology workers, in: Nigeria Proceedingsof the 2006 ACM SIGMIS CPR conference on computer personnelresearch: Forty four years of computer personnel research: achieve-ments, challenges & the future. Claremont, California, USA, 2006:pp. 205–212.

[6] D.P. Darcy, M. Ma, Exploring Individual Characteristics and Pro-gramming Performance: Implications for Programmer Selection. IEEEInternational Conference on System Sciences, in: HICSS’05, Proceed-ings of the 38th Annual Hawaii (03–06 January), 2005, pp. 314a–314a.

[7] S.A. Frangos, Motivated humans for reliable software products,Microprocessors and Microsystems 21 (10) (1997) 605–610.

[8] T.W. Ferratt, L.E. Short, Are information systems people different:an investigation of motivational differences, Management Informa-tion Systems Quarterly 10 (4) (1986) 377–387.

[9] J.M. Burn, J.D. Couger, L. Ma, Motivating IT professionals, TheHong Kong challenge Information & Management 22 (5) (1992) 269–280.

[10] K.R. Linberg, Software developer perceptions about software projectfailure: a case study, Journal of Systems and Software 49 (2–3) (1999)177–192.

[11] S.J. Smits, E.R. McLean, J.R. Tanner, Managing high achievinginformation systems professionals, in: A.L. Lederer (Ed.), Proceed-ings of the 1992 ACM SIGCPR Conference on Computer PersonnelResearch (Cincinnati, Ohio, United States, April 05–07). SIGCPR’92,1992, pp. 314–327.

[12] J.D. Couger, Comparison of motivating environments for program-mer/analysts and programmers in the US, Israel and Singapore.System Sciences. Vol. IV: Emerging Technologies and ApplicationsTrack, in: Proceedings of the Twenty-Second Annual Hawaii Inter-national Conference on, vol. 4, 1989, pp. 316–323.

[13] J.D. Couger, H. Adelsberger, Environments: Austria compared to theUnited States, SIGCPR Comput. Pers. 11 (4) (1988) 13–17.

[14] J.D. Couger et al., Commonalities in motivating environments forprogrammer/analysts in Austria, Israel, Singapore, and the U.S.A,Information & Management 18 (1) (1990) 41–46.

[15] J.D. Couger, A. Ishikawa, Comparing motivation of Japanesecomputer personnel versus these of the United States. SystemSciences. in: Vol. IV: Proceedings of the Twenty-Eighth HawaiiInternational Conference on, vol. 4, 1995, pp. 1012–1019.

[16] J.D. Couger, S.C. McIntyre, Motivating norms for artifical intelli-gence personnel, in: Proceedings of the Twentieth Hawaii Interna-tional Conference on System Sciences. Hawaii Int. Conference Syst.Sci., vol. 4, 1987, p. 370.

[17] M. Sumner, S. Yager, D. Franke, Career orientation and organiza-tional commitment of IT personnel, in: Proceedings of the 2005 ACMSIGMIS CPR Conference on Computer Personnel Research (Atlan-ta, Georgia, USA, April 14–16). SIGMIS CPR’05, 2005, pp. 75–80.

[18] R.A. Mata-Toledo, E.A. Unger, Another look at motivating dataprocessing professionals, SIGCPR Comput. Pers. 10 (1) (1985) 1–7.

[19] L.F. Capretz, Personality types in software engineering, InternationalJournal of Human Computer Studies 58 (2) (2003) 207–214.

[20] O.E.M. Khalil et al., What motivates Egyptian IS managers andpersonnel: Some preliminary results, Proceedings of the ACMSIGCPR Conference (1997) 187–192.

[21] H. Kym, W.-W. Park, Effect of cultural fit/misfit on the productivityand turnover of is personnel, Proceedings of the 1992 ACM SIGCPRconference on Computer personnel research (1992) 184–190.

[22] F.R. Tanner, On motivating engineers. Engineering ManagementConference. IEMC’03. Managing Technologically Driven Organiza-tions: The Human Side of Innovation and Change, 2003, pp. 214–218.

[23] L. Peters, Managing software professionals, in: IEMC’03 Proceed-ings. Managing Technologically Driven Organizations: The HumanSide of Innovation and Change (IEEE Cat. No. 03CH37502). IEEE,2003, pp. 61–66.

[24] J.L. Wynekoop, D.B. Walz, Revisiting the perennial Question: Are ISPeople Different? The Database for Advances in Information Systems29 (2) (1998) 62–72.

[25] E. Jordan, A.M. Whiteley, HRM practices in information technologymanagement Proceedings of computer personnel research conference(SIGCPR) on Reinventing IS: managing information technology inchanging organizations: managing information technology in changingorganizations. Alexandria, Virginia, United States, 1994, pp. 57–64.

[26] H.G. Enns, T.W. Ferratt, J. Prasad, Beyond Stereotypes of ITProfessionals: Implications for IT HR Practices, Communications ofthe ACM 49 (4) (2006) 106–109.

[27] J.E. Moore, Personality characteristics of information systemsprofessionals, in: Proceedings of the 1991 conference on SIGCPR,1991, p. 140.

[28] W.C. Miller, J.D. Couger, L.F. Higgins, Comparing innovation stylesprofile of IS personnel to other occupations. IEEE InternationalConference on System Sciences, in: HICSS’93, Proceedings of the26th Annual Hawaii, vol. iv, 1993, pp. 378–386.

[29] M. Igbaria, G. Meredith, D.C. Smith, Career orientations ofinformation systems employees in South Africa, The Journal ofStrategic Information Systems 4 (4) (1995) 319–340.

[30] H. Kandeel, K. Wahba, Competency models for human resourcedevelopment: case of Egyptian software industry. Managing Infor-mation Technology in a Global Environment. 2001 InformationResources Management Association International Conference. IdeaGroup Publishing, 2001, pp. 117–121.

[31] R.T. Turley, J.M. Bieman, Competencies of exceptional and nonex-ceptional software engineers, Journal of Systems and Software 28 (1)(1995) 19–38.

[32] R. Agarwal, T.W. Ferratt, Retention and the career motives of ITprofessionals, in: Proceedings of the ACM SIGCPR Conference,2000, pp. 158–166.

[33] P.H. Cheney, Effects of Individual Characteristics, OrganizationalFactors and Task Characteristics on Computer Programmer Produc-tivity and Job Satisfaction, Information & Management 7 (4) (1984)209–214.

http://www.scs.carleton.ca/~beau/PM/Standish-Report.html

http://www.scs.carleton.ca/~beau/PM/Standish-Report.html


[34] C.W. Crook, R.G. Crepeau, M.E. McMurtrey, Utilization of thecareer anchor/career orientation constructs for management of I/Sprofessionals, SIGCPR Comput. Pers. 13 (2) (1991) 2–23.

[35] D.K. Goldstein, An updated measure of supervisor-rated job perfor-mance for programmer/analysis, in: Proceedings of the ACMSIGCPR Conference on Management of information SystemsPersonnel (College park, Maryland, United States, April 07–08),1988, pp. 148–152.

[36] M.K. Hsu et al., Career satisfaction for managerial and technicalanchored IS personnel in later career stages, SIGMIS Database 34 (4)(2003) 64–72.

[37] R.A. Zawacki, Motivating the IS people of the future, Informationsystems management (Inf. syst. manage.) 9 (2) (1992) 73–75.

[38] D.C. Smith, H.L. Speight, Antecedents of turnover intention andactual turnover among information systems personnel in South AfricaProceedings of the 2006 ACM SIGMIS CPR conference on computerpersonnel research: Forty four years of computer personnel research:achievements, challenges & the future. Claremont, California, USA,2006, pp. 123–129.

[39] D.J. Couger, S.C. McIntyre, Motivation Norms of KnowledgeEngineers compared to those of Software Engineers, Journal ofManagement Information Systems 4 (3) (1987/1978) 82–93.

[40] J.H. Im, S. Hartman, Rethinking the issue of whether IS peopleare different from non-IS people, MIS Quarterly 14 (1) (1990)1–2.

[41] M.E. Myers, Motivation and performance in the information systemsfield: a survey of related studies, SIGCPR Comput. Pers. 13 (3) (1991)44–49.

[42] S. Ramachandran, S.V. Rao, An effort towards identifying occupa-tional culture among information systems professionals, in: Proceed-ings of the 2006 ACM SIGMIS CPR conference on computerpersonnel research: Forty four years of computer personnel research:achievements, challenges & the future. Claremont, California, USA,2006, pp. 198–204.

[43] R. Agarwal, T.W. Ferratt, Crafting an HR strategy to meet theneed for IT workers, Communications of the ACM 44 (7) (2001)58–64.

[44] R. Agarwal, T.W. Ferratt, Recruiting, retaining, and developing ITprofessionals: an empirically derived taxonomy of human resourcepractices, Proceedings of the ACM SIGCPR Conference (1998) 292–302.

[45] R. Agarwal, T.W. Ferratt, Enduring practices for managing ITprofessionals, Communications of the ACM 45 (9) (2002) 73–79.

[46] N. Baddoo, T. Hall, D. Jagielska, Software developer motivation in ahigh maturity company: a case study, Software Process: Improvementand Practice 11 (3) (2006) 219–228.

[47] J.M. Burn, et al., Job expectations of IS professionals in Hong Kong,in: Proceedings of the 1994 ACM SIGCPR Computer PersonnelResearch Conference on Reinventing IS: Managing informationTechnology in Changing Organizations: Managing informationTechnology in Changing Organizations (Alexandria, Virginia, UnitedStates, March 24–26, 1994, pp. 231–241.

[48] A. Garden, Maintaining the spirit of excitement in growing compa-nies, SIGCPR Comput. Pers. 11 (4) (1988) 10–12.

[49] K. Klenke, K.-A. Kievit, Predictors of leadership style, organizationalcommitment and turnover of information systems professionals, in:A.L. Lederer (Ed.), Proceedings of the 1992 ACM SIGCPR Confer-ence on Computer Personnel Research (Cincinnati, Ohio, UnitedStates, April 05–07). SIGCPR’92, 1992: pp. 171–183.

[50] B.L. Mak, H. Sockel, A confirmatory factor analysis of IS employeemotivation and retention, Information & Management 38 (5) (2001)265–276.

[51] F. Niederman, M.R. Sumner, Job turnover among MIS profession-als: an exploratory study of employee turnover, in: Proceedings of the2001 ACM SIGCPR Conference on Computer Personnel Research(San Diego, California, United States), 2001, pp. 11–20.

[52] C.M. Ridings, L.B. Eder, An Analysis of IS technical career pathsand job satisfaction, SIGCPR Comput. Pers. 20 (2) (1999) 7–26.

[53] J.B. Thatcher, Y. Liu, L.P. Stepina, The role of the work itself: Anempirical examination of intrinsic motivation’s influence on ITworkers attitudes and intentions, in: Proceedings of the ACMSIGCPR Conference, 2002, pp. 25–33.

[54] A.L.J. LeDuc, Motivation of programmers, SIGMIS Database 11 (4)(1980) 4–12.

[55] F. Niederman, M. Sumner, Decision paths affecting turnover amonginformation technology professionals, in: Proceedings of the 2003SIGMIS conference on Freedom in Philadelphia: leveraging differ-ences and diversity in the IT workforce, April 10–12, Philadelphia,Pennsylvania, 2003, pp. 133–142.

[56] M. Santana, D. Robey, Perceptions of control during systemsdevelopment: effects on job satisfaction of systems professionals,SIGCPR Comput. Pers. 16 (1) (1995) 20–34.

[57] A. Garden, Behavioural and organisational factors involved in theturnover of high tech professionals, SIGCPR Comput. Pers. 11 (4)(1988) 6–9.

[58] R.A. Checchio, Creating a motivating environment in softwaredevelopment. Experience with the Management of Software Projects1989, in: Proceedings of the Third IFAC/IFIP Workshop, Pergamon,1990, pp. 81–86.

[59] Y. Li, et al., Motivating open source software developers: influence oftransformational and transactional leaderships Proceedings of the2006 ACM SIGMIS CPR conference on computer personnelresearch: Forty four years of computer personnel research: achieve-ments, challenges & the future. Claremont, California, USA, 2006,pp. 34–43.

[60] S.J. Smits, E.R. McLean, J.R. Tanner, A longitudinal study of I/Scareers: synthesis, conclusion, and recommendations, in: Proceedingsof the 1997 ACM SIGCPR Conference on Computer PersonnelResearch (San Francisco, California, United States, April 03–05,1997, pp. 36–48.

[61] E.S. Andersen, Never the twain shall meet: exploring the differencesbetween Japanese and Norwegian IS professionals, in: Proceedings ofthe 2002 ACM SIGCPR Conference on Computer PersonnelResearch (Kristiansand, Norway, May 14–16). SIGCPR’02, 2002,pp. 65–71.

[62] P.C. Lee, The social context of turnover among informationtechnology professional, in: Proceedings of the 2002 ACM SIGCPRConference on Computer Personnel Research (Kristiansand, Norway,May 14–16), 2002, pp. 145–153.

[63] M.F. Reid, et al., Affective commitment in the public sector: the caseof IT employees Proceedings of the 2006 ACM SIGMIS CPRconference on computer personnel research: Forty four years ofcomputer personnel research: achievements, challenges & the future.Claremont, California, USA, 2006, pp. 321–332.

[64] E. Richens, HR strategies for IS professionals in the 21st century,Proceedings of the ACM SIGCPR Conference (1998) 289–291.

[65] A.W. Morales, Salary survey 2005, Software Development 13 (11)(2005) 32–42.

[66] J.E. Dittrich, J. Daniel Couger, R.A. Zawacki, Perceptions of equity,job satisfaction, and intention to quit among data processingpersonnel, Information & Management 9 (2) (1985) 67–75.

[67] S.E. Gambill, W.J. Clark, R.B. Wilkes, Toward a holistic model oftask design for IS professionals, Information and Management 37 (5)(2000) 217–228.

[68] J.D. Procaccino et al., Journal of Systems and Software 78 (2) (2005)194–203.

[69] P. Carayon, et al., Job characteristics and quality of working life inthe IT workforce: the role of gender, in: Proceedings of the 2003SIGMIS Conference on Computer Personnel Research: Freedom inPhiladelphia–Leveraging Differences and Diversity in the IT Work-force (Philadelphia, Pennsylvania, April 10–12), 2003, pp. 58–63.

[70] R. Agarwal, T.W. Ferratt, Toward understanding the relationshipbetween IT human resource management systems and retention: Anempirical analysis based on multiple theoretical and measurementapproaches, in: Proceedings of the ACM SIGCPR Conference, 2002,pp. 126–138.


[71] M.K. Hsu et al., Perceived career incentives and intent to leave,Information & Management 40 (5) (2003) 361–369.

[72] H.I. Rubin, E.F. Hernandez, Motivations and behaviors of softwareprofessionals Proceedings of the ACM SIGCPR conference onManagement of information systems personnel, College park, Mary-land, United States, 1988, pp. 62–71.

[73] K. Honda, et al., Research on work environment for softwareproductivity improvement, in: Proceedings of COMPSAC 85. TheIEEE Computer Society’s Ninth International Computer Softwareand Applications Conference (Cat. No. 85CH2221-0). IEEE Comput.Soc. Press., 1985, pp. 241–248.

[74] Y. Fujigaki, Stress analysis of software engineers for effectivemanagement. Human Factors in Organizational Design and Man-agement – III, in: Proceedings of the Third International Symposium,North-Holland, 1990, pp. 255–258.

[75] A.C. Nelson, C. LeRouge, Self esteem: moderator between rolestress fit and satisfaction and commitment? in: Proceedings ofthe 2001 ACM SIGCPR Conference on Computer PersonnelResearch (San Diego, California, United States), 2001, pp. 74–77.

[76] P.C. Lee, Career plateau and professional plateau: impact on workoutcomes of information technology professionals. SIGCPR Com-put. Pers. 20, 4 (August), 2002, pp. 25–38.

[77] M.R. Tanniru, S.M. Taylor, Causes of turnover among dataprocessing professionals – some preliminary findings, in: Proceedingsof the Eighteenth Annual ACM SIGCPR Computer PersonnelResearch Conference (Washington, D.C., United States, June 04–05), 1981, pp. 224–247.

[78] E.R. McLean, S.J. Smits, J.R. Tanner, The importance of salary onjob and career attitudes of information systems professionals,Information and Management 30 (6) (1996) 291–299.

[79] S.A. Thomas, S.F. Hurley, D.J. Barnes, Looking for the humanfactors in software quality management, in: 1996 InternationalConference on Software Engineering: Education and Practice(SE:EP’96), 1996, p. 474.

[80] J.D. Couger, Comparison of motivation norms for programmer/analysts in the Pacific Rim and the U.S., International Journal ofInformation Systems 1 (3) (1992) 16–30.

[81] J.D. Couger, Motivators vs. demotivators in the IS environment,Journal of Systems Management 39 (6) (1988) 36–41.

[82] K.M. Bartol, D.C. Martin, Managing Information Systems Person-nel: A Review of the Literature and Managerial Implications, MISQuarterly 6 (Special Issue) (1982) 49–70.

[83] V.L. Almstrum, What is the attraction to computing? Communica-tions of the ACM 46 (9) (2003) 51–55.

[84] J.J. Baroudi, M.J. Ginzberg, Impact of the technological environmenton programmer/analyst job outcomes Communications of the ACM29 (6) (1986) 546–555.

[85] D. Lending, N.L. Chervany, The changing systems development job:a job characteristics approach, in: Proceedings of the 1997 ACMSIGCPR Conference on Computer Personnel Research (San Fran-cisco, California, United States, April 03–05, 1997, pp. 127–137.

[86] K. Mannaro, M. Melis, M. Marchesi, Empirical Analysis on theSatisfaction of IT Employees Comparing XP Practices with OtherSoftware Development Methodologies, Lecture Notes in ComputerScience (2004) 166–174.

[87] S. Hertel, S. Niedner, G. Hermann, Motivation of software develop-ers in Open Source projects: an Internet-based survey of contributorsto the Linux kernel, Research Policy 32 (2003) 1159–1177.

[88] J. Roberts, I. Hann, S. Slaughter, Understanding the motivations,participation and performance of Open Source Software developers: alongitudinal study of the Apache projects. Carnegie Mellon Univer-sity Working Paper, 2004.

[89] T.W. Ferratt, H.G. Enns, J. Prasad, Instrument Validation forInvestigating a Model of Employment Arrangement Fit for ITProfessionals, in: Proceedings of the ACM SIGMIS CPR Conference,2003, pp. 168–178.

[90] T.W. Ferratt, H.G. Enns, J. Prasad, Employment arrangement fit forIT professionals: An examination of the importance of fit components,Proceedings of the ACM SIGMIS CPR Conference (2004) 25–29.

[91] D.K. Goldstein, J.F. Rockart, An Examination of Work-relatedCorrelates of Job Satisfaction in Programmer/Analysts, MIS Quar-terly 8 (2) (1984) 103–115.

[92] R.H. Rasch, H.L. Tosi, Factors affecting software developers’performance: an integrated approach, Management InformationSystems Quarterly 16 (3) (1992) 395–413.

motivation in software engineering: a systematic literature review

Documents