ArticlePDF Available

What Do We Know about Developer Motivation?

Authors:

Abstract and Figures

Software engineers will do better work and stay with a company if they are motivated - as a result the success of software projects is likely to improve. The authors use the findings from their in-depth review of the 92 studies published in the last 25 years on software engineer motivation to give an overview of what managers need to know to improve motivation among their employees.
Content may be subject to copyright.
voice of evidence
92 I E E E S O F T W A R E P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y 0 74 0 -7 4 5 9 / 0 8 / $ 2 5 . 0 0 © 2 0 0 8 I E E E
E d i t o r : F o r r e s t S h u l l n F r a u n h o f e r C e n t e r f o r E x p e r i m e n t a l S o f t w a r e E n g i n e e r i n g ,
M a r y l a n d n f s h u l l @ f c - m d . u m d . e d u
What Do We Know about
Developer Motivation?
Tracy Hall, Helen Sharp, Sarah Beecham, Nathan Baddoo,
and Hugh Robinson
S
oftware developers do better work and
stay with one company if they’re moti-
vated—indeed, evidence exists that devel-
oper motivation affects project produc-
tivity,
1
software quality,
2
and a project’s
overall success.
3
By improving how they
manage software developers’ motivations, compa-
nies could significantly improve their ability to de-
liver good-quality software systems.
To explore what we know about what motivates
developers, we systematically analyzed 92 studies
on software developer motivation published be-
tween 1980 and 2006.
4
Our analysis shows that
motivation influences many important aspects of
project success. Timely project delivery, productiv-
ity, and adherence to budgets, as well as increases
in staff retention and reduced absenteeism, are all
related to motivation. Our analysis also shows that
controlling these factors isnt straightforward.
Study selection
To identify which studies to analyze, we searched
eight popular publication portals as well as key
software engineering conference proceedings,
journals, and authors. We searched specifically for
studies on motivation in a software engineering
context, identifying more than 2,000 potential pa-
pers and rejecting approximately 1,500 of these (on
the basis of titles and abstracts) as irrelevant to our
focus. We read the remaining 519 papers in full to
establish our nal list. The 92 papers we chose were
originally published in the ACM Sigcpr Computer
Personnel, various IEEE proceedings, the Com-
munications of the ACM, MIS Quarterly, and the
Journal of Systems and Software. The studies varied
hugely in how researchers measured motivation, the
context in which they studied it, and the methods
they used.
Who are software engineers?
In 1980, Daniel Cougar and Robert Zawacki were
the first to report on computing personnel’s moti-
vations, extending the well-established but generic
Job Characteristics Theory
5
to this group.
6
They re-
ported that computing personnel need growth and
learning and enjoy a challenge but have low needs for
socializing. This work has significantly influenced
subsequent thinking on developers motivations.
Software engineering has evolved in various ways
since this early work. The context in which develop-
ers work is more complex than ever. In addition, it’s
increasingly obvious that although software devel-
opers might generally have similarities as a profes-
sional group, individual developers vary.
Our analysis throws more light on how and why
this is. In particular, it suggests two dimensions of
motivation unrecognized in earlier work: controllers
and moderators. Controllers are internal character-
Software engineer characteristics
Growth oriented
Introverted
Autonomous
Achievement oriented
Technically competent
Marketable
Creative
And a need for (to)
Variety
Challenge
Identify with group
Competent supervison
Feedback
Contribute
Involvement in personal goals
Individual personality
Managerial leanings
Technical leanings
Innate abilities
MBTI score
Environment/context
State of profession
Career stage
Culture
Job role/type
Organization
Mediates + / -
Different software engineer motivators
Orientate toward
Figure 1. Motivating factors for software
developers. Software engineers’ personal
characteristics are mediated by their
personality and the environment in which
they work. These personal characteristics
orient software engineers toward responding
to particular motivators.
Web Extra
Experimental
method and
data details at
www.computer.
org/portal/pages/
software/content/
WebExtra.html.
July/August 2008 I E E E S O F T WA R E
93
VOICE OF EVIDENCE
istics such as how introverted people are,
their skill sets, and internal needs that con-
trol which motivators affect an individual
developer.
7
Moderators are demographic
considerations such as personality, career
stage, role, and culture that moderate how
strong each characteristic is for a given de-
veloper. For example, a young developer
trying to buy a house or start a family will
likely be more motivated by money and less
by challenge, whereas a seasoned developer
established and secure in his or her job will
likely be more motivated by challenge and
recognition for quality work. This devel-
oper will likely move to another workplace
to gather more knowledge and experience
if the work becomes mundane, whereas the
young developer will likely stay or move for
a higher salary. Figure 1 shows how sets of
motivators are tailored to individual devel-
opers characteristics, which are mediated
by personality and environmental factors.
8
Our analysis suggests that before managers
can focus on an effective set of motivators
for an individual developer, they must con-
sider contextual factors for that developer.
How we manage motivation
Having established that the way software
developers respond to motivators varies ac-
cording to context, let’s consider their spe-
cific motivators. Tables 1 and 2 present the
motivators reported in the 92 studies we
analyzed. Table 1 shows general motiva-
tors relevant to software developers in their
work; Table 2 shows motivators specific to
software engineering work. In the first table,
we can see that the most frequently reported
motivator relates to work tasks. This sug-
gests that to get the best work from develop-
ers, managers must carefully match tasks to
individuals and comprehensively brief them
on these taskscontext in terms of their pur-
pose and the way individual tasks fit into the
overall development. In the second table, we
can see that software developers particu-
larly respond to the challenging, dynamic,
problem-solving aspects of software engi-
neering tasks.
Table 1 also shows that good manage-
ment and employee participation are often
reported as general motivators. Also, many
less-frequently reported motivators from
Table 1 relate to good management. For
example, providing feedback, recognition,
autonomy, and resources are specific good
management practices. This suggests that
significant motivational benefits might arise
from implementing good basic practices.
Many of the studies reported in the
92 papers dont interpret their findings in
terms of existing motivation theory,
9
so
their findings’ wider implications arent
always clear. Classic motivation theory
recognizes that some motivators are more
likely than others to affect behavior. In par-
ticular, Frederick Herzberg defines the no-
tion of intrinsic and extrinsic motivators.
10
Intrinsic motivators relate to the work itself
Table 1
General motivators for software developers
General motivators Examples of study findings
No. of studies that
report on motivation
Identify with the task Clear goals, personal interest, knowing a tasks purpose and how it fits with
the whole, job satisfaction; producing an identiable piece of quality work
20
Good management Senior management support, team-building, good communication 16
Employee participation Involvement in company, working with others 16
Career path Opportunity for advancement, promotion prospects, career planning 15
Variety of work Making good use of skills, being stretched 14
Sense of belonging Supportive relationships 14
Rewards and incentives Increased pay and benets linked to performance 14
Recognition Recognized for a high-quality, good job done based on objective criteria 12
Technically challenging work Work isn’t mundane and is technically challenging 11
Development needs addressed Training opportunities exist to widen skills; opportunity to specialize 11
Feedback Colleagues and managers provide feedback on work 10
Job security Stable working environment and a basic level of job security 10
Autonomy Freedom to carry out tasks, letting roles evolve 9
Work-life balance Flexibility in work times, caring manager or employer, work location 7
Empowerment Responsibility for the task is assigned to the (empowered) person 6
Appropriate working conditions Working environment, good equipment, tools, physical space, quiet 6
Making a contribution/task signicance Degree to which the job has substantially affects others’ lives or work 6
Trust Trusting and respecting other people 4
Equity People are treated and managed fairly 3
Sufcient resources A basic level of resources exists for the job 2
Working in successful company Financial stability 2
94 I E E E S O F T W A R E w w w . c o m p u t e r. o r g / s o f t w a r e
VOICE OF EVIDENCE
and primarily affect the behavior of peo-
ple who, like developers, typically have
high achievement needs. Extrinsic motiva-
tors are external to the work itself, such as
working conditions and general good man-
agement—these have less influence on typ-
ical software developer behavior.
Figure 2 shows developers’ intrinsic and
extrinsic motivators. It suggests that the
extrinsic nature of general good manage-
ment practices means that these practices
will likely have limited impact on behavior.
However, the intrinsic nature of task-based
issues means that managing developers
tasks effectively will have more long-term
impact. In other words, managers must
provide challenging problem-solving tasks,
explicitly recognize quality work, and give
developers autonomy to do their jobs. Man-
aging these factors effectively will engage
developers and excite them in their work.
S
oftware engineering has evolved sig-
nificantly in recent years. Radical new
forms of working, including agile meth-
ods and globally distributed development,
emphasize the importance of developers hu-
man aspects. This software engineering evo-
lution coupled with the increasing imperative
to deliver successful software projects means
that it’s more important than ever that we
manage developer motivation effectively.
Our results are a first step toward being able
to do so in today’s complex and dynamic
software engineering environments.
Acknowledgments
The UK’s Engineering and Physical Science
Research Council supported this research un-
der grant EPSRC EP/D057272/1.
References
1. J. Procaccino and J.M. Verner, “What Do
Software Practitioners Really Think about
Project Success: An Exploratory Study,J.
Systems and Software, vol. 78, no. 2, 2005,
pp. 194–203.
2. B.W. Boehm,
Software Engineering Econom-
ics, Prentice-Hall, 1981.
3. S.A. Frangos, “Motivated Humans for Reli
-
able Software Products,” Microprocessors
and Microsystems, vol. 21, no. 10, 1997, pp.
605610.
4. S. Beecham et al., “Motivation in Software
Engineering: A Systematic Literature Re-
view,” to be published in Information and
Software Technology J., 2008; doi:10.1016/
j.infsof.2007.09.004.
5. J.R. Hackman and G.R. Oldman,
Motivation
through the Design of Work: Test of a Theory,
Academic Press, 1976.
6. D.J. Couger and R.A. Zawacki,
Motivating
and Managing Computer Personnel, John
Wiley & Sons, 1980.
7. A. Maslow,
Motivation and Personality,
Harper & Row, 1954.
8. H. Sharp et al., “Models of Motivation in
Software Engineering,” to be published in In-
formation and Software Technology J., 2008;
doi:10.1016/j.infsof.2008.05.009.
9. T. Hall et al., “A Systematic Review of Theory
Use in Studies Investigating the Motivations of
Software Engineers,” to be published in ACM
Trans. Software Eng. and Methodology, 2008;
tosem.acm.org/Upcoming.php.
10. F. Herzberg,
The Motivation to Work, 2nd
ed., Chapman & Hall, 1959.
Tracy Hall is a reader at Brunel University. Contact her at
tracy.hall@brunel.ac.uk.
Helen Sharp is a senior lecturer at the Open University.
Contact her at h.c.sharp@open.ac.uk.
Sarah Beecham is a research fellow at Brunel Univer-
sity. Contact her at sarah.beecham@brunel.ac.uk.
Nathan Baddoo is a senior lecturer at the University of
Hertfordshire. Contact him at n.baddoo@herts.ac.uk.
Hugh Robinson is a professor at the Open University.
Contact him at h.m.robinson@open.ac.uk.
Inherent in SE
Challenging
Changing
Problem-solving
Beneficial
Life-cycle models
Scientfic
Experimental
Team working
Development
practices
Intrinsic Extrinsic
Identify with the task
Career paths
Variety of work
Recognition for work done
Development needs addressed
Technically challenging work
Autonomy
Making a contribution
Empowerment/responsibility
Trust/respect
Equity
Employee participation
Good management
Sense of belonging
Rewards and incentives
Feedback
Job security
Good work/life balance
Appropriate working conditions
Successful company
Sufficient resources
Motivators
Figure 2. Intrinsic and extrinsic motivators for software developers. Software
engineers’ motivators are divided into those intrinsic to the work they do and
extrinsic to that work. Also, intrinsic motivators are either specific to the
work’s software engineering aspect or related more generally to the work.
Table 2
Software-engineering-specific motivators
Software engineering
motivators Examples of study findings
No. of studies that
report on motivation
Challenge Software engineering is a challenging profession. 4
Change Techniques and problems change constantly; work is dynamic. 4
Benet Developers create something to benet others or enhance well-being 3
Problem solving Developers understand and solve problems 3
Team work Developers work in a team of other professionals rather than alone. 2
Science Developers make observations, identify, describe, engineer, investigate and theorize,
or explain a phenomenon.
2
Experiment Developers try something new or use experimentation to gain experience. 2
Development practices Developers use, for example, object-oriented, Extreme Programming, or prototyping practices. 2
... También se tuvo en cuenta el trabajo de Bechamn et al. [19], quienes realizaron una revisión sistemática de estudios existentes de motivación en desarrolladores e identificaron las características de los ingenieros de software. Por último, se consideró el trabajo de Hall et al. [20] que identifica los motivadores generales de los desarrolladores de software. ...
... De manera contrastante, el subfactor 1.3 (media promedio 3,9) identifica retos abiertos en los cuales deben seguir trabajando las diferentes instituciones para lograr fortalecer el perfil del estudiante de informática como ingeniero de software en los siguientes aspectos: propender por espacios de práctica en los que el estudiante pueda orientar su trabajo en actividades relacionadas con el desarrollo de software (25); involucrarse de manera activa en la planificación y gestión de los proyectos en los cuales participa (25); lograr que las prácticas pedagógicas aplicadas por los docentes del área de ingeniería de software sean altamente significativas para que contribuyan a su formación profesional (37); fomentar la motivación del estudiante hacia el área de ingeniería de software (39); y perfilarlo como un desarrollador exitoso de la industria (40). Por su parte, el subfactor 1.2 (media promedio 3,99) identifica oportunidades de mejora: la necesidad de una adecuada administración del tiempo del estudiante para fomentar su formación integral (20), el fortalecimiento de espacios que enamoren a los estudiantes con la creatividad (26, 27) y la importancia de buscar alta competencia técnica (17). En el factor 2, presentado en la tabla 4, el subfactor 2.2 muestra un balance positivo en la percepción de los estudiantes con respecto a sus relaciones con los docentes (promedio 4,01). ...
... Los ítems identificados para este trabajo están sustentados en el perfil esperado de los estudiantes de las universidades participantes que parten de una cosmovisión común [18], en el estudio de motivación de estudiantes de ingeniería [6] y en estudios que caracterizan a los ingenieros de software [19,20]. Desde el perfil deseado presentado por Knight [18], se consideraron los siguientes aspectos: el respeto por la individualidad, la formación integral, la importancia del trabajo en equipo (que justifica los aspectos intrínsecos del aprendiz, el trabajo en equipo y las relaciones enriquecedoras con los compañeros de clase), el papel del maestro como referente activo en la formación integral del aprendiz, la búsqueda de significado de toda experiencia y su preparación para el mundo laboral (que justifica identificar la relación con los docentes de manera separada a la calidad de la docencia y procura que las estrategias pedagógicas sean pertinentes y significativas para lograr una efectiva inserción en el mundo laboral). ...
Article
Full-text available
El estudio de la motivación de los futuros profesionales de desarrollo de software es de vital importanciateniendo en cuenta el fenómeno de alta demanda no satisfecha de estos profesionales y la responsabilidad de la academia de propender por un proceso de enseñanza-aprendizaje significativo y activo que logre comprometer positivamente a los estudiantes. Los objetivos contemplados fueron: a) identificar los aspectos que inciden en la motivación de los estudiantes de informática con énfasis en el área de la ingeniería de software; b) comprobar la fiabilidad y validez del instrumento elaborado; c) identificar los niveles de motivación de la población estudiada. Para el logro de estos objetivos, se diseñó y validó un nuevo instrumento y se realizó el análisis de datos en dos fases para obtener una estructura de factores y subfactores que den cuenta del nivel de motivación. En la primera fase del análisis se obtuvo un modelo estadístico de cuatro factores (atributos de desempeño; relaciones con estudiantes y docentes; desempeño de los docentes; recursos físicos y virtuales) que explican el 71,5 % de la variabilidad. En la segunda fase del análisis se refinó el modelo para identificar los subfactores que lo componen, con lo que se logró un alto nivel de confiabilidad. En cuanto a atributos de desempeño, se evidencia la necesidad de ayudar a los estudiantes a manejar su tiempo; las estrategias pedagógicas muestran poder predictivo sobre la motivación de los estudiantes en el área de ingeniería de software. Se concluye que la estructura de factores y subfactores obtenida con un alto nivel de confiabilidad sirvió como punto de partida para identificar acciones de mejora en las instituciones autoras del artículo; la fiabilidad y validez del instrumento lo perfilan como candidato para ser aplicado en programas similares de otras instituciones.
... Team members have different individual preferences when they self-assign tasks. Nevertheless, the number of studies on this topic is scarce, ex-isting studies investigated developer work motivation in general [3], [10], [16] and did not specifically focus on factors in task allocation in agile software development contexts. ...
... Many studies have found that motivation has a positive impact on software teams. Having motivated software engineers results in higher quality software, more successful projects, better productivity, improved task performance, and a greater sense of accomplishment [3], [16]. High motivation also results in decreased employee turnover, budget overflow, and delays in project delivery [10]. ...
... Many studies have investigated what drives the motivation and satisfaction of software engineers and developers at work [3], [10], [16]. Hall et. ...
Preprint
Full-text available
Self-assignment, where software developers choose their own tasks, is a common practice in agile teams. However, it is not known why developers select certain tasks. It is important for managers to be aware of these reasons to ensure sustainable self-assignment practices. We investigated developers' preferences while they are choosing tasks for themselves. We collected data from 42 participants working in 25 different software companies. We applied Grounded Theory procedures to study and analyse factors for self-assigning tasks, which we grouped into three categories: task-based, developer-based, and opinion-based. We found that developers have individual preferences and not all factors are important to every developer. Managers share some common and varying perspectives around the identified factors. Most managers want developers to give higher priority to certain factors. Developers often need to balance between task priority and their own individual preferences, and managers facilitate this through a variety of strategies. More risk-averse managers encourage expertise-based self-assignment to ensure tasks are completed quickly. Managers who are risk-balancing encourage developers to choose tasks that provide learning opportunities only when there is little risk of delays or reduced quality. Finally, growth-seeking managers regularly encourage team members to pick tasks outside their comfort zone to encourage growth opportunities. Our findings will help managers to understand what developers consider when self-assigning tasks and help them empower their teams to practice self-assignment in a sustainable manner.
... The social order's influence is not strong enough to regulate people's behavior. Literature [e.g., (Hall et al. 2008)] has shown that open source contributors are more motivated by intrinsic motivations rather than external ones. Intuitively, we can hypothesize that IIAG works IIAG can display the prior cheap talk on the differences between the US and Germany's political system [see (Wang and Redmiles 2016a)]. ...
Article
Full-text available
Open source software development (OSS) team members often need to figure out how to initiate a collaboration with a new remote collaborator. An inappropriate strategy could lead to failures in developing cooperation. In this paper, we propose an approach and corresponding intelligent system called IIAG (Initial Interaction Assistant based on Game theory analytics), which identifies and advises its users about strategies for initial interactions with new remote collaborators. IIAG integrates game theory, decision models, and social factors with the collaborative traces mined from empirical project data to achieve this goal. When a user seeks IIAG’s advice, it simulates an individual’s decision processes to find the strategies that yield the best outcomes. Thus, it can advise proper strategies for users. IIAG is evaluated extensively. We design and perform virtual experiments to evaluate IIAG with empirical data collected from three large open source projects. The results show that IIAG can identify the payoff-optimal strategy with over 80% accuracy. We also conduct a lightweight user study to evaluate the IIAG’s usefulness from the potential users’ perspective. The results are also promising. Thus, IIAG can help OSS team members in making informed decisions about interacting with new remote collaborators.
... Beecham et al. conducted a literature review of 92 papers on programmer motivation in 2008, concluding that professional programmers are motivated most by problem solving, by working to benefit others and by technical challenges [4]. Hall et al. framed these as intrinsic motivators, relating them to self-determination theory [17]. ...
Conference Paper
While the techniques to achieve secure, privacypreserving software are now well understood, evidence shows that many software development teams do not use them: they lack the ‘security maturity’ to assess security needs and decide on appropriate tools and processes; and they lack the ability to negotiate with product management for the required resources. This paper describes a measuring approach to assess twelve aspects of this security maturity; its use to assess the impact of a lightweight package of workshops designed to increase security maturity; and a novel approach within that package to support developers in resource negotiation. Based on trials in eight organizations, involving over 80 developers, this paper demonstrates that (1) development teams can notably improve their security maturity even in the absence of security specialists; and (2) suitably guided, developers can find effective ways to promote security to product management. Empowering developers to make their own decisions and promote security in this way offers a powerful grassroots approach to improving the security of software worldwide.
... Privacy Champions, like other engineers [30], enjoy solving challenging tasks and appreciate the recognition of their efforts (see Section 4.3.1). Thus, organisations and peers should stimulate their curiosity, encourage them to use their unique expertise to find privacy-preserving solutions for technical issues, provide intellectual freedom and resources for exploring new approaches and ideas [7], and acknowledge their efforts not only via explicit positive feedback, but also via career promotions and fair compensation for the additional (often voluntary) work they do. ...
Conference Paper
Full-text available
Software development teams are responsible for making and implementing software design decisions that directly impact end-user privacy, a challenging task to do well. Privacy Champions—people who strongly care about advocating privacy—play a useful role in supporting privacy-respecting development cultures. To understand their motivations, challenges, and strategies for protecting end-user privacy, we conducted 12 interviews with Privacy Champions in software development teams. We find that common barriers to implementing privacy in software design include: negative privacy culture, internal prioritisation tensions, limited tool support, unclear evaluation metrics, and technical complexity. To promote privacy, Privacy Champions regularly use informal discussions, management support, communication among stakeholders, and documentation and guidelines. They perceive code reviews and practical training as more instructive than general privacy awareness and on-boarding training. Our study is a first step towards understanding how Privacy Champions work to improve their organisation’s privacy approaches and improve the privacy of end-user products.
... (Lars Kurth, 2010) Platform:  Presentation "Digital Platforms & Ecosystems" (Ghazawne, 2015)  Presentation "Platform Shift: How New Biz Models Are Changing the Shape of Industry" (M. Van Alstyne, 2015)  Paper "Platform Strategy Survey" (Parker & Alstyne, 2014) Community perspective Demographics  Paper "Open Source Participation Behavior-A Review and Introduction of a Participation Lifecycle Model" (Ehls, 2013) Motivation:  Self-determination motivational theory (Deci, 2012; R. M.  Meta-studies: "What Do We Know about Developer Motivation" (Hall, Sharp, Beecham, Baddoo, & Robinson, 2008) and first part of "Carrots and rainbows: Motivation and social practice in open source software development" (Krogh, Haefliger, Spaeth, & Wallin, 2012)  Paper: "Comparing motivations of individual programmers and firms to take part in the open source movement: From community to business" (Bonaccorsi & Rossi, 2006). ...
Thesis
Full-text available
This thesis is about starting a new commercial open source software project in the digital platform category. The focus is on project initiation (before a community of external contributors exists), where I will cover the concerns that a firm must address right from the start if the project should have a good chance of eventual success. I define success as depending on fulfilment of two conflicting goals: Obtaining a significant community of contributors to the project AND profiting from the resulting software. For its research this thesis uses a wide range of existing literature from different academic areas and sources. For structure I use a new holistic approach looking at my research subjects from 3 perspectives: a business perspective, a community perspective and a technical perspective. A significant output of my research is a new holistic model for project attractiveness that firms can use to evaluate the ability for a project to potentially attract (rather than repel) a community of contributors.
... In skill areas with rapid technological change such as software development, the value of human capital decays as a technology declines in use. Thus, knowledge workers seek opportunities that expose them to newer technologies and applications (Hall, Sharp, Beecham, Baddoo, & Robinson, 2008), corroborating neoliberalism's focus on the entrepreneurial individual seeking to advance the value or their personal capital. ...
Article
Full-text available
Take this job and shove it … or not: Conflicting forces in post-Fordist work - Volume 12 Issue 4 - Bill Curtis
Article
Context Software developers work on various tasks and activities that contribute towards creating and maintaining software applications, frameworks, or other software components. These include technical (e.g., writing code and fixing bugs) and non-technical activities (e.g., communicating within or outside teams to understand, clarify, and resolve issues) as part of their day-to-day responsibilities. Interestingly, there is an aspect of desirability associated with these tasks and activities. Objective However, not all of these tasks are desirable to developers, and yet they still need to be done. This study explores desirability and undesirability of developers for software development tasks. Method Based on semi-structured interviews from 32 software developers and applying a grounded theory research approach, the study investigates what tasks are desirable and undesirable for developers, what makes tasks desirable and undesirable for them, what are the perceived consequences of working on these tasks, and how do they deal with such tasks. Results We identified a set of underlying factors that make tasks (un)desirable for developers, categorised as personal, social, organisational, technical, and operational factors. We also found that working on desirable tasks has positive consequences while working on undesirable tasks has negative consequences. We reported different standard, assisted, and mitigation strategies that aid software practitioners manage developers’ likes and dislikes. Conclusion Understanding these likes and dislikes, contributing factors, and strategies can help the managers and teams ensure balanced work distribution, developers’ happiness, and productivity, ultimately increasing the value developers add to software products.
Chapter
This chapter examines the problems of project managing the software systems development process. It analyses the theoretical background using classical management theory and organisational, contingency theory to evince the importance of communications between developers in the development process. This chapter identifies three levels at which personal communications affect the development process; the interpersonal, the intragroup and the intergroup levels. The chapter introduces a variety of theoretical concepts such as construct theory, basic assumption theory and defence against anxiety in the context of software systems development to help to explain the complexity of human communications. It identifies the importance of specific communication skills that developers need to do their role and some tools available for project managers to help develop these skills. It redefines the role of the manager away from managing resources to facilitating staff communication. This change is presented as a serious challenge for project management.
Article
A summary is presented of the current state of the art and recent trends in software engineering economics. It provides an overview of economic analysis techniques and their applicability to software engineering and management. It surveys the field of software cost estimation, including the major estimation techniques available, the state of the art in algorithmic cost models, and the outstanding research issues in software cost estimation.
Article
This paper focuses on the software engineer, as opposed to some software engineering discipline. The author’s worldwide experience in software development has resulted in concluding that the vast majority of problems encountered while developing software are more people oriented rather than technology based. Therefore, for there to be any improvements in the reliability of software, it may be wise to revisit some of the people issues, otherwise, even the best methods, tools and techniques will not make an impact on the software development process so as to result in higher levels of software quality. Many are the problems which the software engineer is faced with while trying to piece together the complex information systems that the current global market dictates. Lack of office space and engineer concentration, unpaid overtime, non-productive meeting cultures, performance appraisals and absence of team work all contribute to the demotivation of the software engineer. Trying to introduce a new tool or a new technique to a demotivated staff is simply a waste of time. Thus, it is of paramount importance to realize that in the labor intensive software development world, the focus must first be on the human factor. Basic human nature has not changed over the years, therefore, the author sought out solutions from the past regarding the management of people, so as to be applied today in the development of software. This paper concludes with a “euphoria quadrant” so as to provide a simple means for software producing units to gauge their management style and their overall working environment.
Article
This paper summarizes the current state of the art and recent trends in software engineering economics. It provides an overview of economic analysis techniques and their applicability to software engineering and management. It surveys the field of software cost estimation, including the major estimation techniques available, the state of the art in algorithmic cost models, and the outstanding research issues in software cost estimation.
A model is proposed that specifies the conditions under which individuals will become internally motivated to perform effectively on their jobs. The model focuses on the interaction among three classes of variables: (a) the psychological states of employees that must be present for internally motivated work behavior to develop; (b) the characteristics of jobs that can create these psychological states; and (c) the attributes of individuals that determine how positively a person will respond to a complex and challenging job. The model was tested for 658 employees who work on 62 different jobs in seven organizations, and results support its validity. A number of special features of the model are discussed (including its use as a basis for the diagnosis of jobs and the evaluation of job redesign projects), and the model is compared to other theories of job design.
Article
Understanding what software practitioners value and how they define project success has implications for both practitioner motivation and software development productivity. We conducted a survey to discover some of the components of project outcome (in terms of personal/professional aspects as well as the project as a whole) that practitioners consider important in defining project success. We also investigated some of those components that practitioners perceived were important contributors to success through their impact on the development process. Sixty-six practitioners participated in our study. They considered software projects to be successful if they provide them with intrinsic, internally motivating work in developing software systems that both meet customer/user needs and are easy to use.
Article
ObjectiveIn this paper, we present a systematic literature review of motivation in Software Engineering. The objective of this review is to plot the landscape of current reported knowledge in terms of what motivates developers, what de-motivates them and how existing models address motivation.MethodsWe perform a systematic literature review of peer reviewed published studies that focus on motivation in Software Engineering. Systematic reviews are well established in medical research and are used to systematically analyse the literature addressing specific research questions.ResultsWe found 92 papers related to motivation in Software Engineering. Fifty-six percent of the studies reported that Software Engineers are distinguishable from other occupational groups. Our findings suggest that Software Engineers are likely to be motivated according to three related factors: their ‘characteristics’ (for example, their need for variety); internal ‘controls’ (for example, their personality) and external ‘moderators’ (for example, their career stage). The literature indicates that de-motivated engineers may leave the organisation 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 key finding is that the published models of motivation in Software Engineering are disparate and do not reflect the complex needs of Software Engineers in their career stages, cultural and environmental settings.ConclusionsThe literature on motivation in Software Engineering presents a conflicting and partial picture of the area. It is clear that motivation is context dependent and varies from one engineer to another. The most commonly cited motivator is the job itself, yet we found very little work on what it is about that job that Software Engineers find motivating. Furthermore, surveys are often aimed at how Software Engineers feel about ‘the organisation’, rather than ‘the profession’. Although models of motivation in Software Engineering are 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 they are motivated, or the outcome and benefits of motivating Software Engineers.