Abstract Previous discussions of how User Experience (UX) designers and Agile developers can work together have focused on bringing the disciplines together by merging their processes or adopting specific techniques. This paper reports in detail on one observational study of a mature Scrum team in a large organization, and their interactions with the UX designers working on the same project. The evidence from our study shows that Agile development and UX design practice is not explained by rationalized accounts dealing with processes or techniques. Instead, understanding practice requires examining the wider organizational setting in which the Agile developers and UX designers are embedded. Our account focuses on the situatedness of the work by making reference to values and assumptions in the organizational setting, and the consequences that those values and assumptions had for practice. In this organizational setting, cooperation between the Agile developers and UX designers was achieved through ongoing articulation work by the developers, who were compelled to engage a culturally distinct UX design division. Based on this study, insights into culture, self‐organization and purposeful work highlight significant implications for practice. Copyright © 2011 John Wiley & Sons, Ltd.

On the basis of an analysis of contemporaneous materials, we present a history of object-oriented technology from the late 1970s, when object orientation was little known, until the early 1990s, when object-oriented technology was widely accepted across computer science. We identify three phases of emergence: interpretative flexibility; community and dissemination; and pervasiveness. We describe the role of various communities, constituencies, fora and programming languages, and show how the intellectual history of an idea underpinning a technology differs from that technology's path of adoption.

Agile software development promotes feedback, discipline and close collaboration between all members of the development team, and de-emphasises documentation, ‘big design up front’ and hierarchical processes. Agile teams tend to be co-located and multi-disciplinary, and rely heavily on face-to-face communication and seemingly simple physical artefacts to support interaction. In this paper we focus on the functionality of two key physical artefacts – the story card and the Wall – which, individually and in combination, underpin the team’s activity. These artefacts have two main roles – one which enables a shared understanding of requirements and one which facilitates the development process itself. We consider these roles from two perspectives: a notational perspective and a social perspective. This discussion shows how the two perspectives – the notational and the social – intertwine and are mutually supportive. Any attempt to replace these physical artefacts with alternative support for an agile team needs to take account of both perspectives, and the complex relationships between them.

Motivated software engineers make a critical contribution to delivering successful software systems. Understanding the motivations of software engineers and the impact of motivation on software engineering outcomes could significantly affect the industry's ability to deliver good quality software systems. Understanding the motivations of people generally in relation to their work is underpinned by eight classic motivation theories from the social sciences. We would expect these classic motivation theories to play an important role in developing a rigorous understanding of the specific motivations of software engineers. In this article we investigate how this theoretical basis has been exploited in previous studies of software engineering. We analyzed 92 studies of motivation in software engineering that were published in the literature between 1980 and 2006. Our main findings are that many studies of software engineers' motivations are not explicitly underpinned by reference to the classic motivation theories. Furthermore, the findings presented in these studies are often not explicitly interpreted in terms of those theories, despite the fact that in many cases there is a relationship between those findings and the theories. Our conclusion is that although there has been a great deal of previous work looking at motivation in software engineering, the lack of reference to classic theories of motivation means that the current body of work in the area is weakened and our understanding of motivation in software engineering is not as rigorous as it may at first appear. This weakness in the current state of knowledge highlights important areas for future researchers to contribute towards developing a rigorous and usable body of knowledge in motivating software engineers.

This paper describes how we have extended a module structure of the Smalltalk LearningWorks to provide a programming environment deigned for very large scale technology transfer. The ‘module’ is what we have termed the LearningBook, a set of classes and persistent objects, including an HTML browser, programming and visualization tools, and microworlds. The context for this development is a distance learning university course in object technology which has enrolled over 5,100 mature students in its first year – making it the largest such course in the world. While promoting a systems building approach, we have successfully added support for programming in the small and the needs of the isolated novice. Two principles have applied: (i) the programming environment and its modules fit into a consistent framework for personal management of study and (ii) details of complex facilities, such as the class library, are progressively disclosed as knowledge and sophistication grow. The paper shows how these principles have guided the exploitation of LearningBook modules. To provide context, relevant academic background is given. Early informal feedback is reported and a project currently underway to observe in detail how thousands of learners use the Smalltalk programming environment is sketched.

We discuss the ‘software crisis’ as a social and cultural phenomenon, arguing that it can be viewed as (one more) manifestation of postmodernism. We illustrate our argument with a range of examples taken from software engineering, demonstrating software engineering's roots in (and commitment to) modernism and the nature of its fin de siècle predicament. We argue that current attempts within software engineering to respond to the software crisis have not been adequate and that a new, more humble, approach to software development is required.