Nathan Baddoo

Models of motivation in software engineering

Motivation in software engineering is recognized as a key success factor for software projects, but although there are many papers written about motivation in software engineering, the field lacks a comprehensive overview of the area. In particular, several models of motivation have been proposed, but they either rely heavily on one particular model (the job characteristics model), or are quite disparate and difficult to combine. Using the results from our previous systematic literature review (SLR), we constructed a new model of motivation in software engineering. We then compared this new model with existing models and refined it based on this comparison. This paper summarises the SLR results, presents the important existing models found in the literature and explains the development of our new model of motivation in software engineering.

Implementing Software Process Improvement: An Empirical study

In this paper we present survey data characterizing the implementation of SPI in 85 UK companies. We aim to provide SPI managers with more understanding of the critical success factors of implementing SPI. We present an analysis of the critical implementation factors identified in published case studies. We use a questionnaire to measure the use of these factors in ‘typical’ software companies. We found that many companies use SPI but the effectiveness of SPI implementation is variable. Many companies inadequately resource SPI and fail to evaluate the impact of SPI. On the other hand, companies show a good appreciation of the human factors associated with implementing SPI. Copyright

Code Bad Smells: a review of current knowledge

Fowler et al. identified 22 Code Bad Smells to direct the effective refactoring of code. These are increasingly being taken up by software engineers. However, the empirical basis of using Code Bad Smells to direct refactoring and to address ‘trouble’ in code is not clear, i.e., we do not know whether using Code Bad Smells to target code improvement is effective. This paper aims to identify what is currently known about Code Bad Smells. We have performed a systematic literature review of 319 papers published since Fowler et al. identified Code Bad Smells (2000 to June 2009). We analysed in detail 39 of the most relevant papers. Our findings indicate that Duplicated Code receives most research attention, whereas some Code Bad Smells, e.g., Message Chains, receive little. This suggests that our knowledge of some Code Bad Smells remains insufficient. Our findings also show that very few studies report on the impact of using Code Bad Smells, with most studies instead focused on developing tools and methods to automatically detect Code Bad Smells. This indicates an important gap in the current knowledge of Code Bad Smells. Overall this review suggests that there is little evidence currently available to justify using Code Bad Smells. Copyright

A framework for evaluation and prediction of software process improvement success

Abstract The literature shows that software process improvement (SPI) is a current popular approach to software quality and that many companies are undertaking formal or informal SPI programs. However, the anticipated improvements to software quality through SPI have not, as yet, been fully realised. Many companies are neither ready nor equipped to implement a successful SPI program: how do companies evaluate and validate the necessary organisational requirements for the establishment of a successful SPI program? This paper examines the outcomes of a UK study of a sample of SPI programs and compares these programs with an evaluation framework we have developed. The validated framework will help companies conduct a self-assessment of their readiness to undertake SPI.

What Do We Know about Developer Motivation

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.

Does the XP environment meet the motivational needs of the software developer? An empirical study

This paper examines how XP practice meets the motivational needs of software developers. Interactions with peers have been identified by others as one potential area of (de)motivation but little detail is known. The nature of this motivator, as expressed by software developers themselves, was explored through semi-structured interviews with a high maturity high performing team working on safety critical software applications in a traditional environment. From these interviews, we have identified seven themes which are characteristic indicators of peer motivation. We interrogate observational data from five mature XP teams to consider whether and how these characteristic indicators are present in an XP environment. We find that XP teams in our study had processes in place that supported many of the motivational needs voiced by developers coming from a traditional, heavyweight software development environment. However, the XP environment is at odds with other motivational needs.

Software developer motivation in a high maturity company: a case study

In this article, we discuss the impact of software developer motivation on projects. Motivation has been reported to be an important determinant of productivity and quality of work in many industries. In this article, we explore specifically how motivation impacts on development work in software engineering. We describe work previously done to suggest that software developers may have a different profile of motivators to other professionals. We present data collected from nine developers working in a software organisation that has been assessed at CMM level 5. We find that the developers working in this high maturity development environment are highly motivated. We also report relationships between motivation and progress in development work and describe the impact of motivating factors on specific aspects of software development. Our main conclusion is that good software developers are proactive, flexible and adaptable, prepared to share knowledge with team and follow good practice, for example, documenting work. Also, and in particular reference to this high maturity company, good software developers are able to resolve complex problems, innovative and eager to try new technology. The biggest motivators to such performance in a high maturity organisation are pay and benefits, recognition and opportunities for achievement. These are closely followed by technically challenging work, job security and senior management support. Cost, time, product quality — in terms of reliability — and user satisfaction are all moderately good indicators of project success. User satisfaction, however, is the best indicator of all four as its importance assumes a temporal significance as a project progresses. Finally, we found that technical competency, interpersonal skills and adherence to good practices impact favourably on software project success. Copyright

Practitioner roles in software process improvement: an analysis using grid technique

In this paper we present empirical findings from our study of software practitioners. We used the repertory grid technique to collect data from nearly 200 developers, project managers and senior managers in 13 companies. The aim of this study is to investigate the perceptions that different staff groups have regarding their role in SPI. Our results allow improved understanding of the SPI concerns and needs that different staff groups have. We suggest that this improved understanding will enable SPI managers to develop multi-strand SPI implementation strategies which deliver benefit to all staff groups. Delivering SPI benefit to all staff groups increases buy-in at all levels and means that SPI can be more successful in the long term. Our main findings are that all staff groups are in close agreement about their roles in SPI. However software developers often have a limited view of SPI and are unable to perceive themselves in some of the roles that successful case studies on SPI recommend. For example, developers do not see themselves assuming ownership of processes. Copyright

Motivating developer performance to improve project outcomes in a high maturity organization

In this paper we discuss the impact software developer performance has on project outcomes. Project performance remains unreliable in the software industry with many compromised software systems reported in the press. We investigate the impact that developer performance has on aspects of project success and explore how developer performance is motivated. We present interview, focus group and questionnaire data collected from a team of developers working in a software organization that has been assessed at CMM level 5. Our main findings are that developers value technical skills in their colleagues, but appreciate these especially when supplemented with good human skills. Software developers with a proactive, flexible, adaptable approach who are prepared to share knowledge and follow good practice are said to be the best developers. Motivators for these developers are pay and benefits, recognition and opportunities for achievement in their work. Overall, we found that technical competence, interpersonal skills and adherence to good practices are thought to have the biggest impact on software project success.

The jinx on the NASA software defect data sets

Background: The NASA datasets have previously been used extensively in studies of software defects. In 2013 Shepperd et al. presented an essential set of rules for removing erroneous data from the NASA datasets making this data more reliable to use. Objective: We have now found additional rules necessary for removing problematic data which were not identified by Shepperd et al. Results: In this paper, we demonstrate the level of erroneous data still present even after cleaning using Shepperd et al.s rules and apply our new rules to remove this erroneous data. Conclusion: Even after systematic data cleaning of the NASA MDP datasets, we found new erroneous data. Data quality should always be explicitly considered by researchers before use.