Paul Ralph

A Proposal for a Formal Definition of the Design Concept

A clear and unambiguous definition of the design concept would be use- ful for developing a cumulative tradition for research on design. In this article we suggest a formal definition of the concept design and propose a conceptual model linking concepts related to design projects. The definition of design incorporates seven elements: agent, object, environment, goals, primitives, requirements and con- straints. The design project conceptual model is based on the view that projects are temporal trajectories of work systems that include human agents who work to design systems for stakeholders, and use resources and tools to accomplish this task. We demonstrate how these two conceptualizations can be useful by showing that 1) the definition of design can be used to classify design knowledge and 2) the conceptual model can be used to classify design approaches.

Grounded theory in software engineering research: a critical review and guidelines

Grounded Theory (GT) has proved an extremely useful research approach in several fields including medical sociology, nursing, education and management theory. However, GT is a complex method based on an inductive paradigm that is fundamentally different from the traditional hypothetico-deductive research model. As there are at least three variants of GT, some ostensibly GT research suffers from method slurring, where researchers adopt an arbitrary subset of GT practices that are not recognizable as GT. In this paper, we describe the variants of GT and identify the core set of GT practices. We then analyze the use of grounded theory in software engineering. We carefully and systematically selected 98 articles that mention GT, of which 52 explicitly claim to use GT, with the other 46 using GT techniques only. Only 16 articles provide detailed accounts of their research procedures. We offer guidelines to improve the quality of both conducting and reporting GT studies. The latter is an important extension since current GT guidelines in software engineering do not cover the reporting process, despite good reporting being necessary for evaluating a study and informing subsequent research.

Report on the Second SEMAT Workshop on General Theory of Software Engineering (GTSE 2013)

Many academic disciplines have general theories, which apply across the discipline and underlie much of its research. Examples include the Big Bang theory (cosmology), Maxwells equations (electrodynamics), the theories of the cell and evolution (biology), the theory of supply and demand (economics), and the general theory of crime (criminology). Software engineering, in contrast, has no widely-accepted general theory. Consequently, the SEMAT Initiative organized a workshop to encourage development of general theory in software engineering. Workshop participants reached broad consensus that software engineering would benefit from better theoretical foundations, which require diverse theoretical approaches, consensus on a primary dependent variable and better instrumentation and descriptive research.

The Sensemaking-Coevolution-Implementation Theory of Software Design

Understanding software design practice is critical to understanding modern information systems development. New developments in empirical software engineering, information systems design science and the interdisciplinary design literature combined with recent advances in process theory and testability have created a situation ripe for innovation. Consequently, this paper utilizes these breakthroughs to formulate a process theory of software design practice: Sensemaking-Coevolution-Implementation Theory explains how complex software systems are created by collocated software development teams in organizations. It posits that an independent agent (design team) creates a software system by alternating between three activities: organizing their perceptions about the context, mutually refining their understandings of the context and design space, and manifesting their understanding of the design space in a technological artifact. This theory development paper defines and illustrates Sensemaking-Coevolution-Implementation Theory, grounds its concepts and relationships in existing literature, conceptually evaluates the theory and situates it in the broader context of information systems development.

The dimensions of software engineering success

Software engineering research and practice are hampered by the lack of a well-understood, top-level dependent variable. Recent initiatives on General Theory of Software Engineering suggest a multifaceted variable – Software Engineering Success. However, its exact dimensions are unknown. This paper investigates the dimensions (not causes) of software engineering success. An interdisciplinary sample of 191 design professionals (68 in the software industry) were interviewed concerning their perceptions of success. Non-software designers (e.g. architects) were included to increase the breadth of ideas and facilitate comparative analysis. Transcripts were subjected to supervised, semi-automated semantic content analysis, including a software developer vs. other professionals comparison. Findings suggest that participants view their work as time-constrained projects with explicit clients and other stakeholders. Success depends on stakeholder impacts – financial, social, physical and emotional – and is understood through feedback. Concern with meeting explicit requirements is peculiar to software engineering and design is not equated with aesthetics in many other fields. Software engineering success is a complex multifaceted variable, which cannot sufficiently be explained by traditional dimensions including user satisfaction, profitability or meeting requirements, budgets and schedules. A proto-theory of success is proposed, which models success as the net impact on a particular stakeholder at a particular time. Stakeholder impacts are driven by project efficiency, artifact quality and market performance. Success is not additive, e.g., ‘low’ success for clients does not average with ‘high’ success for developers to make ‘moderate’ success overall; rather, a project may be simultaneously successful and unsuccessful from different perspectives.

The illusion of requirements in software development

This viewpoint explores the possibility that many software development projects may have no useful requirements. Specifically, for problems (e.g., knowledge worker burnout) with two completely different solutions (e.g., better tool support or hire more employees), an analyst may state a goal (e.g., decrease work hours) but more specific desiderata are contingent on the chosen solution. Furthermore, without fully exploring the design space, the designer cannot be sure whether there exists another approach, which would achieve the goal without any commonality with known approaches. In these situations of sparse requirements, analysts may misrepresent design decisions as requirements, creating an illusion of requirements in software development.

Requirements fixation

There is a broad consensus that understanding system desiderata (requirements) and design creativity are both important for software engineering success. However, little research has addressed the relationship between design creativity and the way requirements are framed or presented. This paper therefore aims to investigate the possibility that the way desiderata are framed or presented can affect design creativity. Forty two participants took part in a randomized control trial where one group received desiderata framed as “requirements” while the other received desiderata framed as “ideas”. Participants produced design concepts which were judged for originality. Participants who received requirements framing produced significantly less original designs than participants who received ideas framing (Mann-Whitney U=116.5, p=0.004). We conclude that framing desiderata as “requirements” may cause requirements fixation where designers’ preoccupation with satisfying explicit requirements inhibits their creativity.

Possible core theories for software engineering

Following recent calls for greater attention to theory in software engineering, this paper reviews five theories that provide insight into software engineering behavior - Complexity Theory, Sensemaking-Coevolution-Implementation Theory, the Theory of Boundary Objects, Transactive Memory Theory and the Theory of Cognitive Biases. Rather than providing contradictory explanations, these theories apply at different units of analysis and may therefore be used simultaneously to understand the same software engineering phenomena.

A Framework for Automatic Online Personalization

Inexpensive data collection and storage technologies and a global thirst for information have led to data repositories so large that users may become disoriented and unable to locate desired items, leading to dissatisfaction and session abandonment. Automatically personalizing interfaces can resolve navigational difficulties and improve satisfaction. Recommender systems, which suggest items to users, have become a popular automatic personalization tool, but quality and speed continue to haunt practical applications. In this paper, we identify two fundamental problems with recommender systems. We address these problems by presenting a detailed framework for classifying, understanding and generating personalization heuristics, including recommender systems. We present a high-level survey of current personalization systems showing which areas of the framework have received the most (and least) attention. This analysis provides guidance for future studies and a novel paradigm for coordinating development within the field.

Software development waste

Context: Since software development is a complex socio-technical activity that involves coordinating different disciplines and skill sets, it provides ample opportunities for waste to emerge. Waste is any activity that produces no value for the customer or user. Objective: The purpose of this paper is to identify and describe different types of waste in software development. Method: Following Constructivist Grounded Theory, we conducted a two-year five-month participant-observation study of eight software development projects at Pivotal, a software development consultancy. We also interviewed 33 software engineers, interaction designers, and product managers, and analyzed one year of retrospection topics. We iterated between analysis and theoretical sampling until achieving theoretical saturation. Results: This paper introduces the first empirical waste taxonomy. It identifies nine wastes and explores their causes, underlying tensions, and overall relationship to the waste taxonomy found in Lean Software Development. Limitations: Grounded Theory does not support statistical generalization. While the proposed taxonomy appears widely applicable, organizations with different software development cultures may experience different waste types. Conclusion: Software development projects manifest nine types of waste: building the wrong feature or product, mismanaging the backlog, rework, unnecessarily complex solutions, extraneous cognitive load, psychological distress, waiting/multitasking, knowledge loss, and ineffective communication.