Construction of Case Studies

Chapter 16 presents 16 case studies, some quite short and limited. In this chapter, readers are asked to construct case studies. The process of constructing case studies can be carried out in different ways. One way is to visit a software house for a period of time, identify an interesting event, and report about it in the case study. Another approach is theoretical: the case study is constructed based on a fictional, theoretical analysis of the topic one wants to explore. Another option is to report on an event that happened in the past and tell it as a story. All these options are described in what follows . The described processes are our suggested procedures, and you may alter them if you find it appropriate. As long as one produces a reliable case study that raises stimulating questions for discussion from which the readers can learn, the process of case study construction is of less importance.

Option 1: Construction of a Theoretical Case Study

This option lays out a process for the development of a case study based on the analysis of topics introduced so far in this book. The aim of this process is to highlight the immediate application of the theoretical knowledge described in the book to the real world of software development. Personal experience has an important role in this process as well and should not be ignored. This experience is reflected in the assessment of what topics are relevant, in decisions about what topics should be left in the case study, and in other similar situations.

Our recommended process for the case study construction is composed of six steps. After the process is outlined, it is demonstrated by the construction of a specific case study.

Step 1. Select a topic: Think about a topic you find interesting and relevant for you to discuss.

Step 2. Analyze the nature of the topic: In this stage you are asked to check whether the topic you want to focus on has enough heft to be at the center of a case study. Ask yourself questions such as:

• To what software development activities is the selected topic connected?

• To what players in software development environments is the topic connected?

• What human aspects of software engineering does the topic address?

• Is the topic connected to the individuals of the team or is it connected to the team?

If your answers to the preceding questions indicate that the topic is indeed rich enough and can be connected to different issues in software development environments, it might fit to be a central topic of a case study.

Step 3. Imagine possible situations: Imagine at least two situations in software engineering in which the topic may be relevant. The idea is to check whether there are specific situations in software engineering in which the topic you want to pursue has a significant expression.

Step 4. Write the case study: Start writing down the selected case study. Try to make it as vivid as possible without forgetting to include in it the main issues you wanted to address.

Step 5. Check the scope of the case study: After you complete the first writing (and editing) of the case study, check whether other related topics can be added to the case. Make sure not to alter the focus of the case study. Then, check issues such as: Is your main message conveyed properly? Are the connections between the different topics addressed in the case study clear?

Step 6. Develop questions about the case study: Develop stimulating questions that are appropriate to be explored with respect to the case study you just developed.

Illustration of the Process: Developing a Case Study

Step 1. Select a topic: In this first stage, you are asked to recognize an interesting topic for you to discuss. In our case, an interesting topic is a topic related to software engineering whose human aspects may raise interesting questions, dilemmas, and solutions. In fact, if you just think openly enough you will find that each topic related to software development may have interesting human aspects. For example, think about IDEs (Integrated Development Environments). While the actual installation process of an IDE may be conceived of as a technical issue, if we expand our view we find that IDEs may raise very interesting human-related topics. Here are several human-related questions about IDEs : How should a team select the IDE with which to work? What features of an IDE are more important for a specific development process? A specific project? A specific team?

Following this short analysis we can get the feeling that the concept of an IDE may have the potential to be an appropriate topic to construct a case study around. Consequently, it will be the focus of the case study that we will develop in the next stages.

Step 2. Analyze the nature of the topic: Here are partial answers to the questions we suggest to address to check the fitness of the topic of IDE to be at the center of a case study.

• IDEs are connected to many of the central activities of software development. While good IDEs support the development process, bad IDEs may interfere with development processes. Accordingly, a selection of one IDE over another one may have a significant influence on a software projects success.

• IDEs are connected to the main players involved in software development processes. Because the IDE is the environment in which the code is developed, coordinated, and integrated, it has a significant influence on teamwork, customer s acceptance tests, and more.

• Since IDEs are connected to many of the development process activities, they are naturally related to different human aspects of software engineering. Just think about the potential influence of an IDE that supports refactoring on development processes.

• Features of an IDE have a direct influence on the level of teamwork it supports. Thus, the topic of IDEs is connected to software engineering processes, both on the team level and on the individual level.

Step 3. Imagine possible situations: Here are two software engineering situations in which IDEs may have significant expression.

• A decision process about what IDE to adopt for a specific project. A case study that addresses questions like the following can be built:

  • Evaluation of IDEs: What considerations should be taken into account in the process of selecting an IDE?

  • The inclusion of specific menus, such as testing and refactoring menus : Developers may feel that if a specific IDE, which contains these features, is selected for their project, they will have to apply these activities and may exhibit resistance.

  • Cost versus quality in the assessment of an IDE: If a choice has to be made between an expensive IDE of high quality and a freeware IDE of a lower quality, what considerations should be counted?

• The development process supported by an IDE: Such a case study may address topics such as what software development methods the IDE should support and what main features it should include. With respect to each topic, the case study can present different opinions , suggested by different people in the organization, that stem from different objectives and motives.

Step 4. Write the case study: Start writing down the case study. Try to make it as vivid as much as possible but make sure it is realistic. In what follows, we present one possible case study that focuses on IDEs.

A Case Study about IDEs

IDEIDE is a large software development house, with 400 software engineers and about 100 marketing and administrative employees . The product that gives IDEIDE its prestige and its competitive advantage is a software tool that guides software developers in testing processes.

It was a spring day when one of the senior team leaders , Gil, heard about eXtreme Programming (XP) and wanted to check its fitness for her team. Looking around for the best consultant XP company, she found XPTruth to be the perfect consulting company to introduce XP into IDEIDE. It was clear that the process of introducing XP into IDEIDE would not be smooth since the process by which software was developed in IDEIDE at that time was significantly different from the one that XP advocates. For example, IDEIDE developers used to add and develop features that they had not been asked to develop, developers did not perform unit tests (the QA unit performed the testing), and integration was conducted only after the development processes of several parts of the developed software had been completed.

XPTruth is a two-person consulting company that introduces XP to companies by presenting and illustrating the XP values and practices. In each presentation that the XPTruth team performs , it lets the audience experience the essence of XP as much as possible. Each introduction of XP is summed up by discussing with the audience the fitness of XP to their particular company.

The XPTruth team accepted Gil s invitation to introduce XP to a group of team leaders at IDEIDE. As in other cases, at the end of the presentation, a discussion about the fitness of XP to IDEIDE took place. This discussion raised many interesting and unexpected issues.

Unexpectedly, the team leaders did not talk about the fitness of XP for their company, but rather, they started discussing the testing tool that IDEIDE develops. It seemed like they totally forgot about the attendance of the XPTruth consulting team. The discussion emerged as a response to a short illustration of JUnit, which is a testing framework written by Erich Gamma and Kent Beck, used by developers who implement unit tests in Java ( www.junit.org/index.htm ). The brief JUnit demo raised questions related to the testing software developed by IDEIDE. Among the main questions, the following were raised: In what sense is the JUnit framework different from the testing framework that IDEIDE sells? Should IDEIDE adopt the test-driven development (TDD) approach? At a specific stage, Dan, one of the respected team leaders, raised the following question, which left everyone surprised: Are IDEIDE products tested properly? Don t they contain bugs that could have been avoided if IDEIDE had worked according to the XP practice of TDD? The last question is critical, as IDEIDE is a software house that aims at producing a product that supports software-testing processes.

After about an hour of discussion, during which the XPTruth consultants just listened to the give and take, they were invited to address this topic. To pursue their message, the consultants illustrated an IDE that uses JUnit as its testing framework. The message was clear.

After the lunch break, during which the team leaders had a chance to digest the facts that had just surfaced, the discussion continued . The main topics that were addressed were: Should IDEIDE products include JUnit? Should IDEIDE develop a similar testing framework? Should IDEIDE develop its own products by using JUnit? If defects in IDEIDE s delivered products are found by inspection, how will it inform its customers about them?

Each of these questions led to the expression of many emotions. Some of the team leaders began to be frightened about losing their jobs. Others not only were shamed by the way they developed software, but also started feeling badly that they would have to tell their customers about the defective product that they delivered for so long. IDEIDE s CEO, who attended the meeting, started thinking about the financial consequences of each of the possible answers to the previous questions.

Step 5. Check the scope of the case study: At this stage, after we have completed the composition of the case study, we should check whether other related topics can be added to the case and whether the main message we wanted to deliver by this case study is reflected properly.

Our rereading of the case study reveals that IDEs play a central role in it. IDEs are addressed through software developers attitudes with respect to the adoption of IDEs and the features that IDEs should offer. Here are two additional topics we could have addressed at this stage:

• Refactoring menu: Some IDEs contain a refactoring menu (see Chapter 9, Program Comprehension, Code Inspections, and Refactoring ). Such a tool enables the performance of many refactoring actions more efficiently and more conceptually. More specifically , the refactoring menu enables one to think about the design aspects of each refactoring move instead of being swamped with the details and the technical aspects of the specific refactoring action. After rereading the case study, we decided not to add the topic of refactoring to avoid excess complexity. What we decided to do is to address refactoring in the questions presented to the readership of the next case study.

• Budget: Budget considerations are a central topic in the decisions that the team leaders of IDEIDE will have to make. If you look at the last sentence of the case study, you will see that it addresses this topic. Indeed, this sentence was added only as a result of this step in the process of the case study construction.

Step 6. Develop questions about the case study: At this stage you should develop stimulating questions to be explored with respect to the case study you just developed. Our analysis of the IDEIDE case study revealed that it addresses the following list of topics, with respect to which we can present questions: software development methods, software project management, testing, ethics, decision making, and software teamwork. Among many possible questions that we could present, we chose the following:

1. Imagine that you attended the meeting described in the IDEIDE case study. In your opinion, what specific characteristics of the development process that is currently used in IDEIDE led to the emergence of each of the questions mentioned in the case study?

2. Assume that IDEIDE decided to initiate a process in which it will start checking its products thoroughly. That checking revealed that IDEIDE s products for guiding testing processes contain bugs! In your opinion, what approach should IDEIDE take toward telling its customers about this fact? What does the Code of Ethics of Software Engineering say about such cases?

3. What information do you need to determine whether IDEIDE products are failures or successes as software products? How will you collect this information?

4. Refactoring is an integral part of some of the newer IDEs. What considerations, in your opinion, led the developers of these IDEs to add a refactoring menu to the developed IDE?

So far, we illustrated in detail the process of constructing a case study based on our theoretical analysis of what topics are appropriate to be introduced into the case study, the translation of these topics into human behavior, and their description as a story. In what follows, we present two additional ways by which one can write a case study. These processes start when one visits a company in order to find an interesting story to construct a case study based on it. When composing a case study based on a real event that happens in a software house, you can concentrate either on an event that happened in the past or on a case that happened during your visit to the company. In what follows, we briefly explain the main stages of constructing each type of case study.

Option 2: Construction of a Case Study Based on a Field Study

When constructing a case study based on a field study during a visit to a software house, you should feel like an anthropologist who enters a new society and looks for interesting behaviors to report about. In such cases, one cannot decide ahead of time what the topic of the case study will be; rather, one must arrive with an open mind and start looking for interesting topics that may have the potential to become the heart of a case study.

For describing a case study based on what happens during one s visit to the development site, one should be very sensitive to what goes on. The best way to get such information is to conduct observations (see Chapter 4, Software as a Product ).

Before starting any such observation, you should get the permission of the relevant authorities to conduct these observations. In addition, you should inform the people you are going to observe that they are going to be observed . It is very important to explain to them why you will observe them and what specifically you are going to observe (concentrate only on software development-related issues!). In addition, promise these people that the observations will be used only for the description of the case study, and that their identification will be kept anonymous.

When you start the observations, try to be passive and unseen as much as possible. Such behavior will increase people s trust in your presence. Do not get involved in their daily work. Just keep writing and documenting your observations. When you notice something interesting going on, try to locate all the events that seem to be related to it. By all events we mean all the discussions, remarks, changes in plans, and so forth that seem relevant to your case study. Close attention to details will enable you to report about the event more vividly.

After the completion of the observations, when you feel that you have enough data, start describing the case study. When it is relevant, also describe the development environment, tell about the setting of the development site, and add details such as the number of people involved, their professional background, and any additional details that will enable the readers to construct in their mind a picture of the case study.

After you complete writing the case study, ask the people who participated in the case study to read it and to comment. Their input can be very useful for the case study s improvement. For example, they may explain their own as well as the others behavior. When they react , do not criticize or argue with them. Recall that they are sharing their interpretation. You should listen, try to understand their perspective, and check whether you can use their input for the improvement of your case study.

After you incorporate the participants observations into the case study, read it with fresh eyes and develop relevant questions.

Option 3: Construction of a Case Study Based on an Event in the Past

In the case of describing an event that happened in the past in the software house you are visiting, there are two options. In the first option, you may know about an event that happened in the past. In the second, you must identify an event. In the second case, you can start with interviewing people in the organization to find out whether there is an event that seems to be central in the collective memory of the organization (see Chapter 10, Learning Processes in Software Engineering ). After such an event is recognized, one can continue as described here with respect to the case of a known event.

To describe a case study that happens in a specific company in the past, the best way is to base the case study on the information obtained from different research tools, such as interviews, questionnaires, and related documents. For additional information about these research tools, see Chapter 4, Software as a Product.

Here we briefly elaborate on document analysis, a topic that we did not address in detail in Chapter 4. Documents are written artifacts, like minutes of meetings, discussion groups, procedures used in the company, and any other material that people write during their work. The analysis of documents can be done on different levels. First, one can refer to the chronological details of the described event. Second, one can interpret the hinted tone of what is written, trying to speculate on the motives that led someone to write or say what is written. These interpretations should be validated in later stages with the person who wrote the document and with the quoted people. Third, one can try to connect these interpretations to the atmosphere and culture that characterize the described development site. These speculations should also be validated with the relevant people.

As previously mentioned, after you complete the writing of the case study, it is important to give the involved people time to read it and comment. In this case, such feedback has at least two purposes. First, you will be able to validate your interpretation of the gathered data. Second, these people may shed additional light on what has happened. When they read the case study, they may recall additional relevant details.

After the completion of the validation stage and the addition of the relevant details, you can move to the development of questions.