The definitive version can be found at : http://onlinelibrary.wiley.com/ Copyright Wiley [Full text of this article is not available in the UHRA]

Provides notice of upcoming conference events of interest to practitioners and researchers.

Current approaches to detecting bad smells in code are mainly based on software metrics. We suggest that these methods lack precision in detecting bad smells, and we propose a code pattern-based approach to detecting bad smells. However before such a pattern-based approach can be implemented, Fowler's original definitions of bad smells need to be made more precise. Currently Fowler's definitions are too informal to implement in a pattern-searching tool. In this paper we use an expert panel to evaluate our enhanced definitions for five of Fowler's bad smells. We use a questionnaire to survey four experts' opinions of our bad smell definitions. Our results show that the experts basically agree with our enhanced definitions of the message chains, middle man and speculative generality bad smells. However, there are strong disagreements on our definitions of the data clumps and switch statements bad smells. We present enhanced definitions on the basis of these expert opinions.

Abstract The SPE taxonomy of evolving software systems, first proposed by Lehman in 1980, is re‐examined in this work. The primary concepts of software evolution are related to generic theories of evolution, particularly Dawkins' concept of a replicator, to the hermeneutic tradition in philosophy and to Kuhn's concept of paradigm. These concepts provide the foundations that are needed for understanding the phenomenon of software evolution and for refining the definitions of the SPE categories. In particular, this work argues that a software system should be defined as of type P if its controlling stakeholders have made a strategic decision that the system must comply with a single paradigm in its representation of domain knowledge. The proposed refinement of SPE is expected to provide a more productive basis for developing testable hypotheses and models about possible differences in the evolution of E‐ and P‐type systems than is provided by the original scheme. Copyright © 2005 John Wiley & Sons, Ltd.

We investigate the impact of pair programming on the long term evolution of software systems. We use system dynamics to build simulation models which predict the trend in system growth with and without pair programming. Initial results suggest that the extra effort needed for two people to code together may generate sufficient benefit to justify pair programming.

Recent articles in EJIS have discussed whether or not Information Systems is a ‘discipline’. In The Structure of Scientific Revolutions, Kuhn states that a scientific discipline can be identified by reference to its underlying belief system, the ‘paradigm’ or ‘disciplinary matrix’, to which all workers in that field must commit. An important element of Kuhn's model is the notion of ‘scientific communities’. We consider here the belief system underlying Software Engineering (SE). We examine the extent to which a belief system analogous to the disciplinary matrix of a Kuhnian science can be identified in SE. Our preliminary fieldwork has comprised an examination of books used by SE students and practitioners, and in-depth interviews with a number of practitioners. The results of this study suggest that the current status of the theory of SE parallels Kuhn's ‘pre-paradigm’ stage of scientific development. At this early stage, theorists and practitioners are divided into schools. These schools are based on differences in the beliefs and models forming their disciplinary matrices. We conclude that the application by analogy of Kuhn's view of scientific activity to SE is justifiable. Our findings can assist both SE theorists and practitioners in improving the understanding of how and why software development projects succeed or fail. Our findings also provide a framework within which to place the beliefs, models and values which underlie SE. Such a framework can contribute to the discussion as to whether the software development-related aspects of Information Systems can be considered to be a discipline, and if so how that discipline is structured.

Despitethe possible presence of Trojan Horses in the user's process, the reference monitor has no choice but to believe that the access request made by a process reflects the user's wishes" ([GM90,