ArticlePDF Available

Insights from Expert Software Design Practice

Article

Insights from Expert Software Design Practice

Abstract

Software is a designed artifact. In other design disciplines, such as architecture, there is a well-established tradition of design studies which inform not only the discipline itself but also tool design, processes, and collaborative work. The 'challenge' of this paper is to consider software from such a 'design studies' perspective. This paper will present a series of observations from empirical studies of expert software designers, and will draw on examples from actual professional practice. It will consider what experts' mental imagery, software visualisations, and sketches suggest about software design thinking. It will also discuss some of the deliberate practices experts use to promote innovation. Finally, it will open discussion on the tensions between observed software design practices and received methodology in software engineering.
A preview of the PDF is not available
... Therefore, in practice, CASE tools are mostly used for documentation of mature or final models, and most engineers and designers prefer to perform their modeling activities on whiteboards or flip charts in the early design phases (Chen et al. 2003;Cherubini et al. 2007;Covi et al. 1998;Mangano et al. 2010;Petre 2009). ...
... First of all, engineers and designers need to switch their focus frequently while working on the same task (Myers et al. 2008;Petre 2009;Zannier and Maurer 2007). This requires frequent changes of abstraction levels (Cherubini et al. 2007) as well as navigation between related diagrams (Myers et al. 2008;Petre 2009). ...
... First of all, engineers and designers need to switch their focus frequently while working on the same task (Myers et al. 2008;Petre 2009;Zannier and Maurer 2007). This requires frequent changes of abstraction levels (Cherubini et al. 2007) as well as navigation between related diagrams (Myers et al. 2008;Petre 2009). We call the first type of navigation vertical navigation and the second type horizontal navigation. ...
Article
Full-text available
Most engineers and designers prefer to use large drawing boards such as whiteboards or flip charts for the initial collaborative sketching of a system’s models. Large interactive displays have recently begun to replace these physical drawing boards, blurring the line between freehand sketching and toolkit-aided modeling. While digital boards offer more flexibility in drawing and navigating models, they must also provide appropriate cognitive support for frequent shifts of focus and navigation between related artifacts. Furthermore, automated assistance in uncovering potential inconsistencies and contradictions between model sketches would be beneficial so that users do not get lost amid their sketches. In this paper, we discuss an approach to create relationships between the elements of informal hand-drawn sketches on large interactive displays by combining fuzzy search with classic information retrieval techniques. The identification and maintenance of relationships is particularly challenging because we are working with hand-drawn and hand-lettered model sketches rather than the syntactically clean models created with digital modeling toolkits. We evaluated our approach by analyzing 89 model sketches from 16 industry projects and found that it identifies relations between sketched model elements with high precision and recall.
... The effect of working memory and experience on programming skill is mediated through programming knowledge [3]. Experts possess sophisticated mental imagery representing software designs, which they can mentally manipulate and externalise as design and communication resources [25]. ...
... Similarly, work by Bielaczyc, Pirolli, and Brown found that training in self-regulation strategies leads to significantly greater programming performance [3]. When it comes to expert software engineers, their systematic and self-reflective methods are a large part of what makes them experts [9] and these self-regulation skills manifest as the deliberate systematic practices which expert programmers and teams use to structure their work [15]. ...
... Even worse, it can mean committing too early to design decisions that cannot be reversed without significant costs, when it would be more desirable to keep many alternative options open for consideration. In fact, the skilful management of such provisionality is a defining characteristic of expert software designers [52]. Agile proposes to manage these risks by employing short iteration cycles and frequent customer feedback. ...
Article
Full-text available
Managing design-time uncertainty, i.e., uncertainty that developers have about making design decisions, requires creation of “uncertainty-aware” software engineering methodologies. In this paper, we propose a methodological approach for managing uncertainty using partial models. To this end, we identify the stages in the lifecycle of uncertainty-related design decisions and characterize the tasks needed to manage it. We encode this information in the Design-Time Uncertainty Management (DeTUM) model. We then use the DeTUM model to create a coherent, tool-supported methodology centred around partial model management. We demonstrate the effectiveness and feasibility of our methodology through case studies.
... For example, mechanical engineers rarely commence modelling a new product directly using a CAD tool; instead, they commonly produce hand-drawn sketches on paper, whiteboard or other physical surfaces, in order to reflect on their ideas individually or sharing with others. The importance of sketching activities in the conceptual design stages has been pointed out in a number of domains (Schütze et al. 2003;Petre 2009;Eckert et al. 2012). ...
Chapter
Full-text available
This chapter discusses the possible future of using S-BPM in production industry, including prospective obstacles and potential opportunities. It commences by proposing a framework representing the fundamental values of S-BPM relevant for its contribution to production enterprises: agility. These values are derived from the agile approach to software development. It is shown how S-BPM supports them in several ways; specifically 1. Individuals and interactions are supported by the notational simplicity in S-BPM. 2. Working software is supported by the ability of S-BPM to seamlessly integrate processes along life cycles and value chains. 3. Customer collaboration is supported by the widely shared semantics of S-BPM modelling constructs. 4. Responding to change is supported by the ability to encapsulate process functionalities by means of subjects in S-BPM. The principal obstacles are identified for the use of S-BPM in industrial practice, in a way to achieve the four agile values. They include a widespread perception of process modelling as a routine task (not a creative activity), security concerns for core production processes, organizational cultures where there is a strong sense of hierarchy and silo mentality, and a desire for global control flow. Based on the size of each obstacle and the degree to which S-BPM is already prepared to address them, the beginnings of a roadmap towards industrial fitness are then developed. For this purpose, the metaphor of a “compass” is introduced to give orientation to future S-BPM research within a four-dimensional space of opportunities. A specific S-BPM project in the food industry, as part of the SO-PC-Pro project, is presented to show common drivers and challenges of S-BPM implementations for production processes within this four-dimensional space. Finally, the compass is used for identifying further domains that share similar issues likely to be solved using an agile approach supported by S-BPM. The architecture-engineering-construction (AEC) domain is presented as an example of such a domain.
Article
Software design involves the process of understanding the requirements and creating the artifacts that specify these requirements as the product to be built. The specification of the requirements ultimately happens in code. Intermediate abstraction mechanisms, such as domain modeling languages, software design and architecture patterns, programming paradigms, and design fragments, assist software engineers to specify requirements further into the final designs as implementations. However, in the absence of commonly agreed-upon building blocks that assist software engineers in tracing the design specification across software elements, these abstraction mechanisms become sources of unintended errors. Consequently, despite the availability of many software development lifecycle processes and implementation tool support, designs erode and drift from their intent quicker than anticipated.
Conference Paper
Requirements engineers model the system of interest from different points of view by creating numerous artifacts. Although they have to deal with a great amount of information, the display space of the devices is limited. This limitation leads to a time consuming navigation through the artifacts. Requirements engineers have to scroll through numerous pages and switch between multiple windows. However, they have to rely on their memory when there is no space left on the screen to view another piece of relevant information. In this research, we propose to develop a novel visualization technique that flexibly creates editable views of a linked set of elements or artifacts where the pieces show different levels of detail according to the user’s demand for the current task. Thus, important parts are shown in detail, while the space taken for displaying unimportant parts is minimized. Our conceptual solution is a combination of the focus+context concept and a magnet-and-spring system. The focus+context concept is responsible for resizing and relocating objects to make space for more relevant information. The magnet-and-spring system is responsible for distributing the distortion caused by the focus+context concept throughout the workspace, such that the distorted view of the information looks more natural. Considering the artifacts of a software development project as a single hypothetical artifact enables us to manage the artifacts in the same way we deal with the objects inside an artifact. Our envisaged tool support should be embeddable in requirements applications and bring its benefits to the applications manipulating requirements artifacts.
Conference Paper
The Augmented Interaction Room is a team room whose walls are outfitted with wall-sized touch screens that are used to create informal diagram sketches. It strives to help stakeholders in fostering a common understanding of a project's most important risk and value drivers by visualizing aspects of a software system from different perspectives and allowing stakeholders to annotate elements that are especially important or critical for project success. In this paper, we discuss how a combination of trace ability techniques and fuzzy search methods can be used to efficiently support the stakeholders' collaboration and their early design and decision making activities by providing an easy and intuitive visualization and navigation approach and by automatically uncovering potential inconsistencies and contradictions in the created sketches. Since the pragmatic methodology of the Augmented Interaction Room encourages stakeholders to work with handwritten sketches rather than with formal modeling languages, the identification and maintenance of trace links is particularly challenging.
Conference Paper
Methodology implementation failure is attributed to developer mediocrity (by management) – not to organizational mediocrity (rigidity or control-driven, process-driven management), or to a lack of adaptation capability in the methodology. In supporting software construction as a creative process, however, we must promote excellence rather than conformity. We argue that we – through principled research -- must pay attention to the interplay between methodology and culture – the local adaptations needed to make things work, understand how the two co-evolve and how they may contribute together to software quality.
Article
Full-text available
The generation of architectural form is by definition a creative activity. As a rule, architects engage in intensive, fast, freehand sketching when they first tackle a design task. This study investigated the process of sketching and revealed that by sketching, the designer does not represent images held in the mind, as is often the case in lay sketching, but creates visual displays which help induce images of the entity that is being designed. Sketching partakes in design reasoning and it does so through a special kind of visual imagery. A pattern of pictorial reasoning is revealed which displays regular shifts between two modalities of arguments, pertaining to both figural and nonfigural aspects of candidate forms at the time they are being generated, as part of the design search. The dialectics of sketching is the oscillation of arguments which brings about gradual transformation of images, ending when the designer judges that sufficient coherence has been achieved.
Article
Protocols of seven practised designers, all undertaking a common design exercise, have been analysed for patterns of reasoning and use of design rules. Patterns of reasoning were found to be shared among designers and not significantly different from reasoning in everyday life. Rules were largely implicit, overlapping, diverse, variously applied, contextually dependent, subject to exceptions and to critical modification. It is argued that rules are derived from underlying types - functional building types, references, spatial gestalts and experiential archetypes - that serve as ‘holding environments’ for design knowledge.
Article
It is clear that human beings have the capacity to retain visual information over brief intervals, and that the representation may take the form of active visualisation. However, the characteristics of the cognitive mechanism(s) or system(s) involved in visualisation and temporary storage of visual information are as yet unclear. Of particular interest are the limitations on the operation of such a system. One suggestion is that the system has a capacity of a single pattern (Phillips, 1983). Other studies have suggested that several patterns may be retained. More recent work has suggested a limitation in terms of pattern complexity or the similarity of pattern elements.Studies of verbal short-term memory have benefited from the exploration of the effects on retention of phonological similarity or word length. Both of these effects constitute limitations on the effective function of verbal “working memory”. This paper will review contrasting views and data on the characteristics of visual short-term memory, in order to assess whether an understanding of this function might benefit from an approach analogous to that used in the theoretical development of verbal short-term memory. It is argued that there are a number of different limitations on visual short-term storage, and that these limitations may be interpreted within the context of a specialised mechanism for short-term visual storage as a component of a working memory system.
Article
Although new technology is widely used for detailed design and image manipulation, its use in the early stages of visual invention is much less common, one reason being that the denotation systems used in paper-and-pencil sketching assist creativity in ways that are poorly understood. Leonardo da Vinci advocated the use of untidy indeterminacies for working out composition, because he believed that they stimulated visual invention. Recent research in cognitive psychology suggests a mental-imagery model that expands Leonardo's theory and provides evidence for cognitive mechanisms that clarify the function of familiar sketch attributes. Sketches may mediate mental translation between spatially depictive and structurally descriptive modes of visual representation. Evidence for a hybrid percept-image theory of ordinary paper sketching is briefly outlined. Some implications of this theory for the development of improved computer sketching systems are briefly discussed.