Software Engineering as a Reflective Practice

This section examines ways a reflective mode of thinking may improve the performance of some of the basic activities that software engineers usually accomplish. Specifically , we describe the reflective practice perspective and suggest specific ways such an approach may be interwoven within software engineering activities. ^[1]

The reflective practice perspective, first introduced by Donald Sch n [Sch n83] [Sch n87], guides professional practitioners (such as architects , managers, musicians , and others) toward the examination and rethinking of their professional creations during and after the accomplishment of the creation process. The working assumption is that the reflection process improves both proficiency and performance within such professions . Analysis of the field of software engineering and the type of work that software engineers usually accomplish [Winograd96] supports the adoption of the reflective practice perspective for software engineering.

The two main books that present the reflective practice perspective are The Reflective Practitioner [Sch n83] and Educating the Reflective Practitioner [Sch n87]. While the first book presents professions in which reflective thinking is (or should be) inherent, the second book focuses on how to educate students of such professions to become reflective practitioners. In these two books, Sch n analyzes the added advantages one may obtain from continuously examining one s practice and one s thinking about one s practice. ^[2]

Laying out the topics that are possible subjects for reflection in software engineering, we may start with the actual creations (the software systems), going through a reflection on the way algorithms are developed and used in software systems, and moving on to skill-related topics such as topics related to human-computer interaction, software development methods , ways of thinking, and so forth. In fact, it seems that we might end up with a rich collection of objects that can be subjects of thought. It might be the result of the fact that software design embraces many aspects such as safety, human interface, ergonomics, graphics, algorithms, and program structure [Singer94].

The main tool, which we will use here in our discussion about being a reflective practitioner, is the ladder of reflection. Sch n [Sch n87] describes the ladder as a vertical dimension according to which higher levels of activity are meta to those below. When one moves up, in this sense, one moves from an activity to reflection on that activity; when one moves down, one moves from reflection to an action that enacts that reflection. The levels of action and reflection on action are described metaphorically as rungs of a ladder. When one climbs up the ladder, one makes what has happened at the rung below an object of reflection (p. 114).

Sch n analyzes ladders of reflection in the context of student-tutor dialogues taking place in the architecture studio. Hazzan [Hazzan02] expands the use of ladders of reflection to student-coach dialogue in a software studio and to individual work. The idea in both cases, as well as in the cases discussed in the continuation of this section, is to illustrate how one can improve one s understanding when reflection is interwoven into the software development process.

In what follows the focus is on the construction of ladders of reflection in different situations. The described cases aim to illustrate how ladders of reflection may promote one s comprehension of the relevant development issue and may lead to insights that eventually may save time and money. We start by illustrating a ladder of reflection that takes place when two programmers, participating in a pair programming session, attempt to formulate , through a reflection process, what heuristic they should use (see Table 10.1). All tables that describe ladders of reflection illustrate the participants thinking/ discourse at each reflection rung.

Table 10.1: A Ladder of Reflection: The Case of Pair Programming

Ladder Rungs	Pair Dialogue
Designing (a process of reflection-in-action)	A: I m going to use a stack here. Does this make sense
Description of designing (takes the form of description with: appreciation , advise , criticism, etc)	B: Good question. Let s explore the nature of the algorithm. Do you remember that in the last retrospective session we discussed a similar problem? What was it about?
Reflection on description of designing ( reflection on the meaning the other has constructed for a description he or she has given)	A: You are right. I m trying to recall. We started by comparing the nature of two projects and concluded that the project we discussed in that retrospective session is similar to what we developed last year. After that, we did a lot of rescue.
Reflection on reflection on description of designing (the parties to the dialogue reflect on the dialogue itself)	B: And, I even remember more clearly that following this retrospective session, we decided to change the format of our retrospective session. But more specifically, on the code level, we decided to change the design. Let s try to think in these directions: redesign and reuse. I guess they will save us a lot of time eventually.

Looking at the various rows in Table 10.1, we can see that the subjects of reflection on each rung are objects of different complexity: While detailed elements are the focus on the first rungs, algorithms, ways of thinking, and development approaches are at the center of the later rungs. It is suggested that such a reflective mode of thinking may improve the comprehension of one s own thinking. As software development is based on team interaction, it is reasonable to assume that the more one is aware of mental processes and ways of thinking (of oneself and of the others), the more teamwork is improved.

In what follows, we construct a ladder of reflection step by step. In each step, we try to explain why and how we move up the ladder. Needless to say, any statement may lead to the construction of many ladders of reflection. Still, we hope that this illustration clarifies how a reflective practice perspective may improve activities that software developers usually accomplish.

This illustrative ladder of reflection is constructed during a code review session (see Chapter 9, Program Comprehension, Code Inspections, and Refactoring ). It ended when the team decided to change the way it runs its code review sessions. This example also illustrates how simple questions that invite reflective processes may lead to decisions about work habits.

Suppose that a software team, which is well trained in constructing ladders of reflection, competes on the development of a huge application for a leading insurance company. If it wins, their startup may become a leader in the market. The financial implications are clear. As usual, the team conducts a weekly code review session. The code review session starts with Developer A saying, In order to implement this function, I used the quick sort algorithm. On the next rung of the ladder, Developer B refers to what Developer A has said and asks, What were the reasons that guided you to select this algorithm? Developer A answers, I just picked the first sort algorithm that came to mind. I usually do not ask myself such questions.

The team leader is shocked, moves to the next rung of the ladder, and says: I must admit that my working assumption was that before each of you implements any particular algorithm you make sure that it is the best algorithm for the particular task at hand. I think that we should make sure that all the algorithms you used in this application are the best ones for their particular purposes. To explain what I mean I would like to give you an example of a project that was developed three years ago in which. . . . The team leader continues describing how in a previous project the entire development process was replaced when it was realized that a wrong process had been used. Then, the team continues with the code review session, analyzing, for each task, the fitness of the algorithms it uses.

After the code review session had ended, all the code was improved without giving up the high programming standards they set in their previous code reviews. As a result, the application s performance and design were improved significantly. The team won the competition and became the leader in the market. The team leader asked Developer B to summarize what happened by moving up to the fourth rung of the ladder. Table 10.2 summarizes the full ladder of reflection constructed during this event.

Table 10.2: A Ladder of Reflection: A Code Review Session

Ladder Rungs	A Dialogue During a Code Review Session
Designing (a process of reflection-in-action)	Developer A: To implement this function, I used the quick sort algorithm
Description of designing (takes the form of description with: appreciation, advise, criticism, etc)	Developer B: What were the reasons that guided you to select this algorithm? Developers A: I just picked the first sort algorithm that came to mind. I usually do not ask myself such questions.
Reflection on description of designing ( reflection on the meaning the other has constructed for a description he or she has given)	Team leader: I must admit that my working assumption was that before each of you implements a particular algorithm, you make sure that it is the best algorithm for the particular task at hand. I think that we should make sure that all the algorithms you used in his algorithm are the best ones for their particular purposes. To explain what I mean, I would like to give you an example of a project that was developed three years ago in which
Reflection on reflection on description of designing (the parties to the dialogue reflect on the dialogue itself)	(After several days) Developer B: I was thinking of what has happened during the last couple of days and I think that we all should learn from it. One important implication would be that in our next code review sessions, each of us has to include a statement that explains why each algorithm is used and what alternatives were considered .

The next code review sessions were managed differently. More attention was placed on explaining what reasons led to specific decisions. This habit also forced each team member to become more reflective about development processes. The team members became more experienced with explaining why they used particular algorithms and consequently improved their problem-solving abilities .

Task  

The ladder just described is only one possible ladder that can be constructed for this case. Suggest two other ladders that start with the first statement on the first rung; each ladder leads to different conclusions.

Ladders of reflection are not restricted to the use of software developers. This tool can also be used with other parties who are involved in the development process, such as the customer. The use of ladders of reflection in such cases is quite important; the literature is full of evidence of crises in software development processes that in many cases result from a misunderstanding between clients and software developers. A reflective mode of thinking, like the one suggested by the reflective practice perspective, may improve one s ability to understand the conceptions held by others in general and customers needs in particular.

The following scenario takes place in a software development environment in which the customer is part of the development environment (such as eXtreme Programming (XP), see Chapter 2, Software Engineering Methods ). Since the customer is on-site for answering questions, it is suggested that when both customer and developers are guided by a reflective mode of thinking, developers, as well as customers, may improve their understanding of the developed application. Table 10.3 presents a ladder of reflection that illustrates how this might happen when the customer, together with the development team, defines the next release/iteration. As described in Table 10.3, sometimes a reflective mode of thinking leads to wider implications than it aims at originally.

Table 10.3: A Ladder of Reflection: A Code Review Session

Ladder Rungs	A Conversation During a Planning Session
Designing (a process of reflection-in-action)	Customer: I want this feature to enable me to get a clear picture of my employees opinions. You see, I consider my employees opinions and experience when I think about the company s strategy. I truly believe that their viewpoint is very important Developer 1: Can you think of a specific situation in which you will use this feature?
Description of designing (takes the form of description with: appreciation, advise, criticism, etc)	Customer: What do you mean? Would you like me to think of a specific case in which I will use it? A specific situation? Interesting. Yes, I can do that. If, for example, the marketing people tell me that one of our customers want a specific feature, I ask the employees opinion about the usefulness of the said feature. If I see that the majority tends to view it as a useful feature, sometimes I consider integrating it into other products as well
Reflection on description of designing ( reflection on the meaning the other has constructed for a description he or she has given)	Developer 2: Can you specify the employees who usually respond to your questions? Customer: Sure, they all have a technical background, know the system very well, and are very loyal workers. I guess this is a partially because of the good and supportive atmosphere that characterizes our company. Developer 3: I do not understand. Don t you ask any of the end users about their opinion with respect to the new feature. Customer: No why should I? I fully trust my employees opinion. But, now you are asking, let me tell you how we were misled once in the past. Based on our survey, we concluded that our customers need a very sophisticated feature. We spent about two developments month on this development. During these two months, another company released a new product and (even worse ) it turned out that this feature was useless. It is clear that we did not gain any competitive advantage from this bad decision. Fortunately, our customers did not leave us. The excellent service of our customer support is well known
Reflection on reflection on description of designing (the parties to the dialogue reflect on the dialogue itself)	Customer: Wow! Let s rethink this feature that I start describing before and develop it in a way that our end users will be able to use it as well. That is, we will be able to also get the end-users opinion. I ˜m so thankful. It is a real twist in my thinking about the introduction of new features to our system.

As can be observed , the customer understanding of what should be developed was improved throughout the session described in Table 10.3. In fact, the customer got the relevant insight only after a reflection mode of thinking was introduced. In this case, the reflection addressed similar situations in the past. We don t argue that such conclusions would not have been reached if customers hadn t been asked to reflect on past experiences. However, it is plausible to assume that such an insight would have arrived later (maybe only after a wrong feature was developed). The contribution of such lessons to software development processes is clear.

Conclusion

This section suggests adding the practice of reflection to software engineering activities. A similar approach is taken by Kerth s framework for project retrospective [Kerth01]. It is argued that a reflective mode of thinking may improve software developers understanding of their and their teammates ways of thinking. It is suggested that as a result, developers may improve their understanding of their own way of software development as well as their understanding of the development environment.

It is important to note that since reflection does not produce new code, some developers (and team leaders ) may not see the benefits of using it. Thus, to be carried out successfully, reflection should be supported by the development environment. A learning organization (discussed in the continuation of this chapter) is one environment that may support, and even promote, a reflective mode of thinking. Learning organizations do not limit their activities to those that yield short-term profits. Rather, energy and resources, which support activities that lead to long- term targets, are invested and allocated as well.

Activities

Select a topic to be the subject for the ladder of reflection. Separate into pairs. Work on the following tasks :

1. Each pair constructs a ladder of reflection with respect to the selected topic. After all pairs complete the construction of their ladders, compare the various ladders.

2. All pairs are given an opening sentence to be presented on the first rung of the reflection ladder. Each pair composes the upper rungs of the ladder. After all pairs construct their ladder, compare the ladders. Discuss similarities and differences among the ladders.

Discussion

1. How can a software team establish a development environment in which a reflective mode of thinking is an inherent part?

2. How should team members respond to one team member who refuses to participate in reflection processes but who has a central role in the development software?

^[1] This section is partially based on [Hazzan02] and on [Hazzan and Tomayko03].

^[2] Sch n did not discuss in his two original books the application of the reflective practice perspective with respect to software engineering. He did address this issue in a later interview [Sch n96].