Building Knowledge through Families of Experiments
IEEE Transactions on Software Engineering
A Critique of Software Defect Prediction Models
IEEE Transactions on Software Engineering
Effects of group task pressure on perceptions of email and face-to-face communication effectiveness
GROUP '01 Proceedings of the 2001 International ACM SIGGROUP Conference on Supporting Group Work
High-order punishment and the evolution of cooperation
Proceedings of the 8th annual conference on Genetic and evolutionary computation
Design for Trustworthy Software: Tools, Techniques, and Methodology of Developing Robust Software
Design for Trustworthy Software: Tools, Techniques, and Methodology of Developing Robust Software
Proceedings of the Second ACM-IEEE international symposium on Empirical software engineering and measurement
Models of motivation in software engineering
Information and Software Technology
Antecedents and consequences of team memory in software development projects
Information and Management
Hi-index | 0.00 |
Organizational Punishment/Penalty is a pervasive phenomenon in many professional organizations. In some software development organizations, punishment measures have been adopted in an attempt to improve software developers' performance, reduce the software defects, and hence ensure software quality. It is unclear whether these measures are effective. This article presents the results of a multi-method field study that analyzes software engineers' perception towards penalty policies in relation to software quality in a software development process. The results were generated via both qualitative and quantitative methods. Through interviews, we collected the individuals' perception towards the penalty policy. By extracting data in a software configuration management system, we identified several patterns of defects change. We found that while a penalty mechanism does help to reduce software defects in daily coding activity, it fails in achieving programmers' maximum work potential. Meanwhile, experienced software programmers require less time to adapt to penalty policies and benefit from exist of less experienced developers. Some additional findings and implications are also discussed.