We apply the biological-behavioral concept of an umwelt, which is how an organism perceives and acts within its environment, to the practice of software development. By writing narrative descriptions of our own software umwelts and iteratively discussing and analyzing them, we develop prompts that can elicit reflection on how and why we relate to software in the ways that we do.

Pattern authors ostensibly are experts on the topic their patterns address. Since most software developers don't share those experts' underlying design values, practices, and principles---let alone their design context---there's a disconnect between what is said in pattern descriptions and that which is perceived and understood by pattern readers. As pattern readers, we will be better equipped to grasp the significance of these software patterns if we also gain insights into the design principles and values that they are based on and some reasons why they "work" the way they do. But it is through experience, practice, and reflection, that we deepen the connections between new-to-us patterns and our existing knowledge, and expand our design umwelt.

ABSTRACTThis essay reflects on my experiences of the past 15 years writing software design patterns and posits that if the patterns community wants to broadly increase pattern literacy, relevancy, and long-term impact, some things need to change. Those changes need to start with pattern writers-like me. Instead of indiscriminately writing ever more patterns, we should focus more on connecting, relating, and refreshing the abundance of existing impactful patterns. Changes also need to be made in how we the community of long-time pattern authors and advocates present and promote patterns to the rest of the world.

Capturing the wholeness of design solutions in order to effectively communicate them to others can be challenging. We posit that patterns are observable phenomena of design solutions. To represent these phenomena, a pattern author needs to generalize and omit information. Experienced designers are able to unfold the essence of the pattern and generate design solutions based on the information that they do find in a pattern description. Not surprisingly, their personal design heuristics play a central role in this. As they create a design solution, they also liberally apply their pre-existing design know-how and heuristics. But novice designers may have more difficulty. As this folding and unfolding of information and knowledge seems to be quite an abstract concept, we have chosen to make our point by discussing elephants. Like patterns, elephants are an observable phenomenon, a pattern in nature. Many different descriptions, representations, and accounts of elephants exist. Many people claim to know what elephants are. Yet they actually have little or limited knowledge of them. This analogy helps to understand how at the same time we both know and do not know what a thing is.

This paper started because we are two authors who plan to make a book from a set of related patterns papers, and in doing so we really want to reach our target audience and provide a practical and useful piece of work. Our approach had two distinct investigation activities. One was to do an informal analysis of books about software processes and methods to gain a better understanding of characteristics and book design practices for this kind of book. The second was to use a combination of interviews and surveys to gather feedback on what readers are looking for when accessing information about software engineering. To better understand our potential readers and how to design our writing for their consumption, we created personas where we incorporated feedback from the reader survey into their personalities and preferences. Finally, we combined our information sources to create guidance for our future work of turning a set of patterns papers into a cohesive whole.

Architects always make decisions in some context. That context shifts and changes dynamically. Different decision-making strategies are appropriate in different contexts. Architecture decisions are at times made under conditions of time pressure, high stakes, uncertainty, and with too little information. At other times, decision-makers have sufficient time to reflect on the decision and consider alternatives. Understanding context is critical to choosing appropriate approaches to architecture decision making. Naturalistic Decision Making (NDM) explains how people make decisions under real-world conditions. This paper investigates NDM in software architecture and studies architecture decisions in their environment and decision-making context. The research approach includes a case study of large technology organizations consisting of a survey, multiple focus groups, and participant observation. Previous studies that touch on NDM in software architecture have mainly focused on decision-making processes or tools or developing decision models. This paper provides three contributions. First, we build on previous studies by other researchers to produce an in-depth exploration of NDM in the context of software architecture. We focus on Recognition-Primed Decision (RPD) making as an implementation of NDM. Second, we present an examination of the decisions made by experienced architects under conditions that can be considered naturalistic. Third, we provide examples and recommendations that help software architects determine when an NDM approach is appropriate for their context.

First, we shape our architecture. Then, our architecture shapes us. As architects we bring part of ourselves to the systems we work with. We evolve with our architectures. In this tutorial we consider the metaphor of "terroir" to understand architectures and their sense of place. Terroir comes from the French word used to describe the set of all environmental factors that affect the observable characteristics of an organism, e. g., the unique set of contextual characteristics of place that influence food crops, coffee, tea, or wine. So too in systems, architectures are uniquely shaped by the culture and context of a place. Factors include people, organization, culture, technology, and tenets shared among the architects and makers. Understanding an architecture is a first step towards evaluating it. The set of concepts and practical tools covered in this tutorial are well suited to being used in conducting architecture analyses and reviews and integrate with any other processes an organization might be using.

ABSTRACTPattern authors intentionally create waypoints---points of interests along a design trail they hope others can traverse. While designers may read others' design advice---be it patterns or stack overflow replies, the heuristics they've personally discovered are equally important. Patterns are just a small part of a much larger body of our design know how. Heuristics, like patterns, can be expressed at various levels. Some are small, simple acts. Others are bigger steps, taken at the beginning of a design journey. This essay explores ways we can grow as designers by becoming more aware of our heuristics, acknowledging the inherent uncertainty in the design process, and learning better ways to articulate and share our heuristics with each other.

ABSTRACTAgile development processes are driven from a product backlog of development items. This paper adds three more patterns to our Magic Backlog collection of patterns to build and structure the backlog for an agile development effort using the outcomes of requirements elicitation and analysis. RULES defines who should be allowed to do what in managing the backlog, SHARED DEFINITIONS deals with defining and consistently using clear criteria for core decisions across the backlog team(s), and REMODEL is about restructuring the overall backlog contents.

Many organizations struggle with efficient architecture decision-making approaches. Often, the decision-making approaches are not articulated or understood. This problem is particularly evident in large, globally distributed organizations with multiple large products and systems. The significant architecture decisions of a system are a critical organization knowledge asset, as well as a determinant of success. However, the environment in which decisions get made, recorded, and followed-up on often confounds rather than helps articulation and execution of architecture decisions. This paper looks at aspects of architecture decision-making, drawing from an industry-based case study. The data represents findings from a qualitative case study involving a survey and three focus groups across multiple organizations in a global technology company. Architects in this organization are responsible for multiple products and systems, where individual products can include up to 50+ teams. The impact is not just on others in the system; architecture decisions also impact other decisions and other architects. The findings suggest recommendations for organizations to improve how they make and manage architecture decisions. In particular, this paper notes the relevance of group decision-making, decision scope, and social factors such as trust in effective architecture decision-making.

This paper extends our Magic Backlog Patterns collection with three additional patterns for managing the work of a program or rather how to deal with coordinating the work of projects which are part of a larger program and where there may be dependencies and shared deployment. While teams within a program may work fairly independently, their work still needs to be coordinated to produce a product. These three patterns, which represent alternative strategies for structuring the backlog of work, are introduced through a story of the correspondence of a business analyst as her hypothetical program moves through different backlog management strategies.

ABSTRACTBilly Vaughn Koen, in Discussion of the Method: Conducting the Engineer's Approach to Problem Solving, defines a heuristic as anything that provides a plausible direction in the solution of a problem, but in the final analysis is unjustified, incapable of justification, and potentially fallible. Software patterns might be considered nicely packaged heuristics in that they provide a context for the problem, and offer plausible solutions along with forces that the designer needs to consider when implementing a solution. Like any heuristic, software patterns come with no guarantees that they will solve the current problem at hand. A dedicated group of authors in the patterns community continues to write patterns, collections of patterns, and more ambitiously weave patterns into pattern languages that attempt to cover paths to solutions in a particular problem space. Are we deluding ourselves about the utility of these efforts? Or is there something important about both the form and use of patterns in the larger context of design heuristics that we need to understand?

ABSTRACTAgile development processes are driven from a backlog of development items. This paper looks at how to apply patterns from our Magic Backlog collection through the use of storytelling. We follow a project through various scenarios from the early days through significant growth into a mature setting and then, finally to a disruptive transition as the project becomes part of a program. Our goal is to focus on common project issues that we believe are experienced by many people involved in software development, and how the use of combinations of patterns, including our own as well as other patterns and practices, can help resolve or mitigate these problems.

ABSTRACTAgile development processes are driven from a backlog of development items. This paper adds three new patterns to our collection of patterns to build and structure the backlog for an agile development effort using the outcomes of requirements elicitation and analysis. The Funnel adds new content to the backlog, the Pipeline prepares backlog contents for implementation, and Maintenance performs continued care of backlog contents. The need to formalize the backlog increases with the size of the project.

To achieve quality systems and products, it is vital to enable and infuse quality work throughout the entire process, rather than piling it on at the end. Thus paying attention to when to this, how to do this, and who is involved can increase quality. This paper presents three patterns from the collection of patterns on being agile at quality: System Quality Specialist, Spread the Quality Workload, and Automate As You Go. System Quality Specialists can define, test, and implement system-quality characteristics that are complex or require specialized skills and expertise to get right. Spreading the Quality Workload throughout the development process keeps the team from being overly burdened with quality-related work at any point in time. Automating First enables teams to streamline their build and testing processes, eliminate tedious or mundane tasks, and allow more time for team members to focus on implementing and testing important system qualities.

A Pattern Writer's Workshop (WW) is a peer-review method to improve pattern or pattern language papers. However, several problems may arise, leading to "ad hoc" review meetings where patterns are not systematically reviewed and authors do not receive useful feedback. Previously, we considered Checklist-based Reading (CBR) and Perspective-based Reading (PBR), which are techniques to improve ad hoc reviews, but some deficiencies were noted. In our focus group, we organized a mini WW using these technique and results are summarized in this paper.

Agile development processes are driven from a backlog of development items. This paper describes patterns to build and structure the backlog for an agile development effort using the outcomes of requirements elicitation and analysis. The need to formalize the backlog increases with the size of the project.

The implementation and release of software products has progressed from a lengthy delivery cycle - the methodical sequential path of "big bang" waterfall product delivery - to the rapid iterative release cycle supported by agile practices. Recently, "continuous delivery" has emerged as a strategy to accelerate product availability. However, only a systematic automation of the build, test and deployment processes in concert with superbly coordinated teams of software practitioners and business partners makes make this possible. However, trade-offs in the optimization of process may act to limit the innovativeness of product output. This panel will discuss approaches, challenges, risks, and strategies for using continuous delivery to competitive advantage.

Professionalism evolves as knowledge and skills mature from craft to commercial practice - often as the result of learnings derived from failure and human hazard. Aviation, medicine, engineering, and architecture are examples of disciplines with an established knowledge base and curriculum of learning and mentorship. These disciplines often require regulated practices executed by certified professionals to ensure the safety and economic value of delivered services. This panel will debate whether we are learning effectively from our experiences and what might be done to accelerate increased software professionalism and product value.

A Pattern Writer's Workshop (WW) is a peer-review method to improve pattern or pattern language papers. However, several problems may arise, leading to "ad hoc" review meetings where patterns are not systematically reviewed and authors do not receive useful feedback. Previously, we considered Checklist-based Reading (CBR) and Perspective-based Reading (PBR), which are techniques to improve ad hoc reviews, but some deficiencies were noted. In this paper, we propose an approach to improve WWs by providing a two-level checklist and refining perspectives for reviewing patterns. An experiment shows the strengths and weaknesses of this new approach.