Folk-wisdom in software engineering suggests that small functions that adhere to the principle of single-responsibility have several advantages over longer, monolithic functions, including improvement in code comprehension. Despite this widespread view, empirical research on the impact of functional decomposition on understanding code is sparse, yet it is central to software development practices.

Practice adaptation in the domain of software engineering (SE) is ubiquitous and well-studied. The main rationale for tailoring lies in the complexity of the environments within which SE projects are implemented. This complexity means that the practices that make up software methodologies are often not fit-for-purpose as-is and must be replaced or adapted to suit local context. However, there is a risk that a practice may be changed in an inappropriate way, with unintended side-effects. For example, altering a practice to reduce documentation may result in a failure to meet standards expectations or the expectations of downstream practices. In this paper, we describe a study that explored the notion of practice equivalence. Our goal was to identify aspects of a practice that are ‘similar’ and might support adaptation. We found that adapted practices must be within the same software function, perform the same action, be compatible in terms of creativity, reasoning and perspectives and have a compatible interface type. Our contributions are the consideration of an as-yet unexplored area of software process that we hope will generate discussion and future research studies and the creation of a strawman framework that will be a starting point for further exploration and evaluation.

The Repertory Grid Technique (RGT) has been applied within the software engineering domain to investigate a variety of topics. These include topics relating to architectural knowledge, team level tacit knowledge, and project success mechanisms. The technique is based on Personal Construct Theory (PCT) and is claimed to be suitable for gaining a deep understanding of peoples’ perspectives on a topic. The essence of RGT is a consideration of similarities and differences, for example, between different project instances. In this paper, we describe a case study in which we applied the technique with the aim of eliciting practitioners’ viewpoints on contextual factors for situated software practices. We interviewed twelve practitioners in three organisations. We found that the RGT approach was challenging to implement for several reasons. Participants had difficulty in choosing specific instances of a software practice, identifying similarities and differences tended to be problematic and causal pathways were not always easy to establish. Our contributions are the highlighting of the challenges that may occur when implementing this technique, an analysis of the issues encountered and some possible mitigation approaches. These may serve as support for SE researchers considering an RGT based study.

Software development practices are carried out in a range of different contexts and there is little evidence to support the likelihood that a specific practice will be effective in a specific context. The need to understand the relationships between practice and context is pressing if we are to support industry in selecting a set of practices that will provide maximum benefit for the project. An evidence based approach requires that, for each practice, we associate a 'context profile' that describes the operating parameters for the practice. Our earlier explorations resulted in a categorisation of the huge number of terms used when describing software development context. We found that some terms could not be included in the context profile because the term described context at a high level, was vague or its meaning was ambiguous. In this position paper, we overview the findings from our explorations of context and present and critique the inadmissible terms with respect to their application to situated software practices. The cataloguing of these terms will benefit researchers by supporting discussion and thus a deeper understanding of context for situated software practices.

The introduction of programming into secondary schools in New Zealand (NZ) has meant that many teachers are preparing programming students at senior level for the New Zealand Certificate of Educational Achievement (NCEA). A recent study showed that many teachers struggle with providing feedback to students on code quality, and indicated a possible issue with the available resources. In this paper, we describe a study to help us understand this phenomenon. We first analysed the data from the earlier study concerning teachers' viewpoints on the available resources. We then analysed the defining curriculum and assessment documents for NCEA, extracting quality-relating terms. We found that all teachers interviewed reported issues with the resources and that there was no clear mapping for quality concepts between the two sets of resources. Our contribution is to expose gaps in the online resources that are problematic from the perspective of teacher and student outcomes.

Practitioners adapt development methodologies to suit local needs, for example, by combining agile and traditional elements. To support this, we need a deeper understanding of the underlying mechanisms behind the various software development approaches, with the aim of finding a perspective that is common to all. In the field of IT, it has been suggested that a change in perspective from ‘technology and people’ to ‘action’ might help address the disconnect between artifact- and people-centric approaches. In this position paper, we explore this idea for software development by considering a change in viewpoint from methodology to patterns of action. Actions are the core functions that are the building blocks for software development and are defined in a lexicon. Possible relationships between actions are depicted in a grammar and processes are modelled as action grammars. We represent some common development methodologies as action grammars and discuss insights gained. Our contributions are the exploration of a novel way of viewing the software process, some insights gained and the exposure of issues with popular terminology.

Many prescriptive approaches to developing software intensive systems have been advocated but each is based on assumptions about context. It has been found that practitioners do not follow prescribed methodologies, but rather select and adapt specific practices according to local needs. As researchers, we would like to be in a position to support such tailoring. However, at the present time we simply do not have sufficient evidence relating practice and context for this to be possible. We have long understood that a deeper understanding of situated software practices is crucial for progress in this area, and have been exploring this problem from a number of perspectives. In this position paper, we draw together the various aspects of our work into a holistic model and discuss the ways in which the model might be applied to support the long term goal of evidence-based decision support for practitioners. The contribution specific to this paper is a discussion on model evaluation, including a proof-of-concept demonstration of model utility. We map Kernel elements from the Essence system to our model and discuss gaps and limitations exposed in the Kernel. Finally, we overview our plans for further refining and evaluating the model.

A growing number of empirical software engineering researchers suggest that a complementary focus on theory is required if the discipline is to mature. A first step in theory-building involves the establishment of suitable theoretical constructs. For researchers studying software projects, the lack of a theoretical construct for context is problematic for both experimentation and effort estimation. For experiments, insufficiently understood contextual factors confound results, and for estimation, unstated contextual factors affect estimation reliability. We have earlier proposed a framework that we suggest may be suitable as a construct for context i.e. represents a minimal, spanning set for the space of software contexts. The framework has six dimensions, described as Who, Where, What, When, How and Why. In this paper, we report the outcomes of a pilot study to test its suitability by categorising contextual factors from the software engineering literature into the framework. We found that one of the dimensions, Why, does not represent context, but rather is associated with objectives. We also identified some factors that do not clearly fit into the framework and require further investigation. Our contributions are the pursuing of a theoretical approach to understanding software context, the initial establishment and evaluation of a construct for context and the exposure of a lack of clarity of meaning in many 'contexts' currently applied as factors for estimating project outcomes.

It is widely acknowledged by researchers and practitioners that software development methodologies are generally adapted to suit specific project contexts.Research into practices-as-implemented has been fragmented and has tended to focus either on the strength of adherence to a specific methodology or on how the efficacy of specific practices is affected by contextual factors.We submit the need for a more holistic, integrated approach to investigating context-related best practice.We propose a six-dimensional model of the problem-space, with dimensions organisational drivers (why), space and time (where), culture (who), product life-cycle stage (when), product constraints (what) and engagement constraints (how).We test our model by using it to describe and explain a reported implementation study.Our contributions are a novel approach to understanding situated software practices and a preliminary model for software contexts.

We know that students solve problems in different ways, but we know little about the kinds of variation, or the degree of variation between these student generated solutions. In this paper, we propose a taxonomy that classifies the variation between correct student solutions in objective terms, and we show how the application of the taxonomy provides instructors with additional insight about the differences between student solutions. This taxonomy may be used to inform instructors in selecting examples of code for teaching purposes, and provides the possibility of automatically applying the taxonomy to existing solution sets.

Different kinds of process model are prescribed for software organizations, and each offers successful project outcomes if followed. There is little evidence that organizations strictly adhere to specific models. We surveyed 195 participants from 51 New Zealand (NZ) software organizations with a view to increasing our understanding of practice implementation in NZ. We found that practices are implemented inconsistently. The implication is that organizations do not follow any one process, either prescribed or adapted, but rather select practices on a project basis and according to some unknown guidelines. Our conclusion is that, rather than attempting to impose or adapt processes at an organizational level, we should instead aim to understand the rationale behind practice selection and how practices combine to make a coherent set. We also found a collaborative, informal, iterative approach to product development with issues around clarity and availability of requirements.

Complex-network theory is a new approach in studying different types of large systems in both the physical and the abstract worlds. In this paper, we have studied two kinds of network from software engineering: the component dependence network and the sorting comparison network (SCN). It is found that they both show the same scale-free property under certain conditions as complex networks in other fields. These results suggest that complex-network theory can be a useful approach to the study of software systems. The special properties of SCNs provide a more repeatable and deterministic way to study the evolution and optimization of complex networks. They also suggest that the closer a sorting algorithm is to the theoretical optimal limit, the more its SCN is like a scale-free network. This may also indicate that, to store and retrieve information efficiently, a concept network might need to be scale-free.

Complex-network theory is a new approach in studying different types of large systems in both the physical and the abstract worlds. In this paper, we have studied two kinds of network from software engineering: the component dependence network and the sorting comparison network (SCN). It is found that they both show the same scale-free property under certain conditions as complex networks in other fields. These results suggest that complex-network theory can be a useful approach to the study of software systems. The special properties of SCNs provide a more repeatable and deterministic way to study the evolution and optimization of complex networks. They also suggest that the closer a sorting algorithm is to the theoretical optimal limit, the more its SCN is like a scale-free network. This may also indicate that, to store and retrieve information efficiently, a concept network might need to be scale-free.

The development of software products is a complex activity with a large number of factors involved in defining success. As real-world experimentation is difficult and costly, researchers have used various techniques in an attempt to model the development process. This field of software process simulation has received substantial attention over the last twenty years. The aims have been to better understand the software development process and to mitigate the problems that continue to occur in the industry by providing support for management decision making.