Illumination of Previous Chapters by Abstraction | Human Aspects of Software Engineering (Charles River Media Computer Engineering)

This section highlights several of the previous chapters of this book from the perspective of abstraction. By doing so, this section is in fact an application of one of the ideas presented in Chapter 7. In Chapter 7, we said that the richness of software engineering enables us to examine it from different perspectives. Here, the lens of abstraction is used.

The first chapter of this book deals with the nature of software engineering, emphasizing its human aspect. Cognitive and social aspects involved in software development are illustrated by describing two working days in the life of software developers. These stories illustrate how much of such days are about human aspects and not about technical aspects. In this sense, these narratives establish the rationale for the book. We use low levels of abstraction (details) to bring to the surface abstract topics, such as communication in teamwork. Such use of abstraction is appropriate when new concepts are introduced. In our case, the new idea is the human aspect of software engineering. In later chapters, some of the details described in Chapter 1, The Nature of Software Engineering, are addressed at higher levels of abstraction.

Task	Specify at least five details related to the human aspect of software engineering that are mentioned in the stories presented in Chapter 1 and are discussed in later chapters at higher levels of abstraction.

Chapter 2 addresses software development methods from the human perspective. It aims to illustrate that both technical and human factors should be considered when one evaluates what software development method to adopt for a specific software project. Specifically, three methods are examined: the Spiral Model, the Unified Process, and eXtreme Programming. For each of these methods we describe how the four basic activities of the paradigm of software engineering ”specifying, designing, coding, and testing ”are implemented. The rationale for this set of activities, on which most of the accepted software development methods are based, is explained in Chapter 8 .

Abstraction is expressed , in this case, in the term paradigm . Paradigm reflects the fact that we capture the shared essence of the activities of which the paradigm consists, while ignoring the details of how each of these activities is implemented by each software development method.

Tasks

With respect to each of the three software development methods described in Chapter 2, explain the specific implementations of the paradigm of software engineering.
The following statements were said by imaginary software engineers . In your opinion, what is common to all of them?
- I need to gain a global view of the application in order to know how this method fits into it.
- I truly believe that if I had a minute to think about these two objects more abstractly, I d come up with the conclusion that they can be extracted into one class. But I must move on to the next development task.
- I need some time to think about the code without being swamped with all the details. I m almost sure that if I could leave now and go jogging, I d come up with a solution. But I must stay as late as all the others on my team.
- I wish I could join the programmers when they write the code. You ask why? I m not sure if this complicated design can be implemented into C++.
During the process of software development, developers should think in terms of different levels of abstraction and move between abstraction levels. For example, when trying to understand customers requirements during the first stage of development, developers must have a global view of the application (high level of abstraction). Conversely, when a developer codes a specific class, a local perspective (on a lower abstraction level) should be adopted. Obviously, there are additional levels of abstraction in between these two levels of abstraction.
- Describe different situations (or activities) in software engineering that require one to think in terms of different levels of abstraction.
- Review the different XP practices and identify those practices that guide software developers to think in terms of different levels of abstraction when appropriate.

Chapter 3, Working in Teams, discusses different topics related to software teamwork, one of which is the structure of software teams. When we discuss hierarchical teams , we refer to the influence of hierarchies on teamwork in the context of software development. Among other influences of hierarchies, we say that Grunts in such a team organization may miss the big picture of what goes on. Consequently, they may have only a narrow understanding of the development environment in general and the developed software in particular. From the perspective of abstraction, these programmers are familiar only with the details and cannot conceive of the developed application from a higher level of abstraction. This narrow perspective limits their understanding of the development activities. For example, they may not understand how the details are connected to each other and how the big picture is composed of them.

An appropriate metaphor for this situation is one s familiarity level with a new city. If one knows only the details of how to arrive from one specific location to another specific location, one s ability to cope with new situations remains limited. Such local understanding may not be sufficient, for example, for the construction of a new path for which one does not have specific instructions. When one has a more global and abstract (less detailed) image of the city, the ability to cope with new situations is improved significantly. In such cases, when one is familiar with connections between different parts of the city, but does not know all the details of all its parts , one may perform better when the need to construct new paths emerges.

We suggest that developers familiarity with the big picture of the developed application may improve their performance in developing specific tasks. One way to achieve this familiarity with the entire picture of the developed application is by the Planning Game (one of the XP practices; see Chapter 2 and Chapter 13, Software Project Estimation and Tracking ). Although each developer is responsible for specific tasks, they all participate in the Planning Game. Playing the Planning Game enables them to become familiar with the entire picture of the developed application. In later development stages, when they have to make decisions related to other parts of the application, this knowledge may be useful.

Chapter 3 also discusses dilemmas that may arise during software development processes. For example, the Prisoner s Dilemma is presented to explain why people tend to compete even in situations when they might gain more from cooperation. Abstraction is expressed in this case since many real-life situations are captured in one theoretical framework ”the Prisoner s Dilemma. In practice, when we face a problem of a similar nature, this abstraction may guide us to ignore the details of the specific situation we are faced with and to consider the solution that this framework offers.

Task

Describe three situations related to software engineering that can be described within the framework of the Prisoner s Dilemma. What features do they have in common? In what sense are they different?
This task continues the city metaphor just presented. Describe how abstraction is expressed in geographical maps. In what ways is this application of abstraction similar to the application of abstraction in software development processes? In what sense are these two applications of abstraction different?
Suggest an example that illustrates how developer s familiarity with the entire picture of the developed application influences the development of one specific task for which the programmer is responsible.

Abstraction is expressed also in Chapter 4, Software as a Product, in Chapter 6, International Perspective on Software Engineering, and in Chapters 7 and 8. With respect to customers (Chapter 4), the customer s requirements themselves are an expression of abstraction. This is because we do not discuss the details of how these requirements are implemented but rather we stay in higher levels of abstraction and describe only the essence of the requirements. With respect to the international perspective on software engineering (Chapter 6), abstraction is expressed by addressing cultural issues. The concept of culture itself is an abstraction, as it captures the similar behavior of many people, ignoring differences among individuals. Chapter 7, which describes different perspectives on software engineering, illustrates abstraction by analyzing properties of the profession of software engineering rather than describing details and procedure. Chapter 8 describes how abstraction became part of the paradigm of software engineering.

Chapter 5 deals with the Code of Ethics of Software Engineering. Not only is the concept of ethics abstract, abstraction is expressed by how the Code of Ethics of Software Engineering is presented. The preamble of the Code of Ethics of Software Engineering, states explicitly that [t]he short version of the code summarizes aspirations at a high level of abstraction. The clauses that are included in the full version give examples and details of how these aspirations change the way we act as software engineering professionals. Without the aspirations, the details can become legalistic and tedious ; without the details, the aspirations can become high sounding but empty; together, the aspirations and the details form a cohesive code. ^[1]

The essence of the Code of Ethics of Software Engineering is discussed in Chapter 5 through the analysis of different scenarios taken from the world of software development. This analysis can be characterized as an examination of the code from a lower level of abstraction. This is because the abstract norms that the code of ethics inspires are illustrated by describing detailed cases and specific actions derived from the code s abstract norms.

Abstraction is expressed in this case also by the fact that situations are characterized not by their details but by the ethical issues they raise. This method of exposition is selected to help software engineers identify situations as specific instances of more abstract cases for which the code of ethics outlines norms that are accepted by the community of software engineers. Such identification may guide software engineers to act according to the code of ethics.

Tasks

Why is the concept of ethics abstract?
Tell a story related to software engineering that raises an ethical dilemma. Based on the Code of Ethics of Software Engineering suggest possible solutions. Tell another story whose solution can be derived from the solutions you offered for the first story. By identifying what the two stories have in common, explain why these similar features are sufficient for deriving the same solutions.

Chapter 9, Program Comprehension, Code Inspections, and Refactoring, and Chapter 10, Learning Processes in Software Engineering, focus on the team and some of its activities during the course of software development. Chapter 9 reviews the topic of program comprehension. This chapter highlights the cognitive aspect of software engineering by presenting different theories of program comprehension and examining code review processes. Abstraction plays a central role in this chapter, as some program comprehension theories use abstraction as their organizing idea. The relevance of abstraction in this context of program comprehension is clear. In the process of program comprehension , one has to move between levels of abstraction. This requires, of course, a lot of awareness on the part of the person who comprehends the computer program.

Task	In what sense does awareness of the existence of different levels of abstraction improve program comprehension processes?

Chapter 10 focuses on learning processes. Specifically, two topics are addressed. The first topic is software engineering as a reflective practice. With respect to this topic, it is illustrated how the construction of a ladder of reflection may increase one s awareness of the existence of different levels of abstraction and, consequently, to increase the complexity of the objects with which one thinks. In other words, the discussion about software engineering as a reflective practice illustrates how one may increase the level of abstraction of one s thinking when reflection is interwoven in the process of software development.

The second topic discussed in Chapter 10 is learning organization. Specifically, Senge s framework for learning organizations [Senge94] was described. According to Senge, one of the dimensions of a learning organization is systems thinking, which helps us see more effectively how to change systems and act more in tune with the larger processes of the natural and economic world around us. In other words, systems thinking is a conceptual framework based on patterns that explain different events as instances of one phenomenon . We have said in that context that systems thinking is about abstraction, since it guides us to ignore details and to examine what different events have in common.

Task	Suggest examples from the world of software engineering that illustrate the idea of systems thinking. Explain connections to the idea of abstraction.

We believe that at this stage readers gain quite a comprehensive picture about how abstraction can be seen in almost every phenomenon related to software engineering. Readers are invited to continue analyzing in a similar manner the next chapters of the book.

^[1] It is stated explicitly in the Code of Ethics of Software Engineering that [t]his Code may be published without permission as long as it is not changed in any way and it carries the copyright notice. These two requests are fulfilled in this book.