PAIR PROGRAMMING IS MORE THAN PROGRAMMING

In software engineering,formal methodsis a fundamental topic. It provide sets of notations in which to express the initial specification and future design steps toward the final program. Computer-aided software engineering (CASE) software tools help us design, develop, and maintain software. Both

Sales module

W/H module

Finance module

Coding

Report Design and testing

FIGURE 5.13 How we divide development tasks affects structure and productivity of a software team.

PAIR PROGRAMMING IS MORE THAN PROGRAMMING 153

are about design. When we have spent a number of hours on working on design using formal methods or CASE, we may wonder how the design can automatically generate executable code, or why we do not design our software just by code so that the design is machine-executable!

5.4.1 Design by Code

Design and coding are intermingled. By design, we mean abstraction and semantic algorithm analysis and bycoding, converting the semantic algorithm analysis into a final executable program in a specific computer language.

However, what is programming itself?

The piece of Java code in Figure 5.14 illustrates that the design of an ATM system has had the following four classes: UserSession, User, ATM and Bank, which respectively handle the session’s options, user information and secu- rity, a menu of possible types of ATM transaction, and bank accounts.

Writing lines 11, 12, 14, and 15 in Figure 5.14 can be compared with solving a deduction problem that requires working out a logical model that describes what we understand about the problem (see Figure 5.15).

Certainly, programming is more than a deduction problem. Looking at lines 01, 04, 05, and 10 in Figure 5.14, we also need to work out a problem of another kind, namely, one about analysis of a flowchart, required in every programming design (see Figure 5.16).

The difference between a deduction problem and a procedural algorithm is a matter of sequential relationships. We may reverse the deduction problems; for example, solving a problem “A B C _?_” is the same as

01 if UserSession.checkAlreadyLogin() return ATM.Error( NOLOGIN );

02 UserSession.selectedOption =

03 ATM.displayOptions(User.authorityLevel);

04 switch(UserSession.selectedOption) 05 {

05 case _ENQUIRY:

06 {

07 ATM.Display(Bank.Balance(User.account));

08 return 1;

09 };

10 case _WITHDRAWL:

11 if ( User.balance >0 and User.requestedAmount <

12 ATM.availableCash )

13 {

14 if(User.balance > 0 and User.requestedAmount <

15 User.balance )

16 {

17 ATM.processWithdraw();

18 }

19 };

20 };

FIGURE 5.14 Automated teller machine (ATM) system.

154 PAIR PROGRAMMING

“_?_ B C D”;“(statement A) and (statement B)”will be the same as“(statement B) and (statement A).”

However, if we reverse the order of a procedural algorithm as in Figure 5.16“inquiry!select options!_?_,”the possible answer can be

“inquiry”again or“withdraw money”rather than“log in.”Artificial intelli- gence tells us that solving both kinds of problem faster is an exploration in a searching space (Luger and Stubblefield 1989) and a pair is able to explore more programming design alternatives than are two individuals working separately (Flor and Hutchins 1991).

User.Account.balance>0 and User.requestedAmount _?_ ATM.availableCash Or

User.Account.balance>0 and User.requestedAmount _?_ User.balance What is ‘‘?’’

Or A B C _?_ What is ‘‘?’’

Select Options

?

Inquiry

? = Login

FIGURE 5.16 Procedural algorithm.

FIGURE 5.15 Deduction problem.

PAIR PROGRAMMING IS MORE THAN PROGRAMMING 155

If we go ahead doing design by code, programmers are simultaneously thinking about requirement comprehension, deduction problems, procedur- al algorithms, scripting, code reading, and so on every minute. A team of programmers paired up should rise to the challenge.

Another challenge for design by code is readability. Since there are few design documents for software maintenance, code reading becomes the only way we can maintain the software. In the end, we have to pay the cost for programming source that is hard to read. Scripts written by two persons should be much more readable than scripts written by an individual. Al- though the termcode readabilityis often used in agile software development, what it means in programming is that writing code is better explained by exploiting depictability and consistency. For example, getSalary() is more easily depicted than Salary(). In short, if you are doing design by code, go for pair programming!

Design by code was not so possible in the old days. Many old version compilers do not support us in writing virtual functions or dynamic data structure. Not until the emergence of object-oriented programming in the early 1990s were computer languages developed in a way that we understand in today’s world. Class inheritance, polymorphisms, and other concepts have now allowed us to do design by code.

5.4.2 Pair Design

We once paired with a smart guy who acted as an observer. The system we wrote had a variety of business logic, and the guy was lost in what we were doing several times! He blamed himself for his distraction. And we gave him a humorous reply:“You are not Stephen Hawking.”

Hawking is a genius mathematician and theoretical physicist but unfor- tunately suffers from motor neuron disease (amyotrophic lateral sclerosis) and has been severely disabled. How can Hawking have something to do with pair programming? But, surely we are not joking.

Studying physical cosmology involves lots of understanding of advanced mathematics,6and your best companion is always pencil and paper. Even though equations are given step-by-step in print, we still need pencil and

6For those programmers who forgot how difficult the mathematics in advanced physics can be, here is the linearized Einstein equation (Wald ; 1984), and we really need pencil and paper to help ourselves out to understand where it comes from and where it will go:

Gð1ịab ẳ 12qcqcgabỵqcqðbgaịc12habqcqdgcdẳ8pTab

156 PAIR PROGRAMMING

paper to understand the logic and work out the calculation. It is very difficult, and for many people simply impossible, to just watch (i.e., read) and think (i.e., do the calculation mentally).

In pair programming, the driver controls the keyboard and mouse and her eyeballs fix on what she writes and she may at any time talk to her partner about what she is writing. It is however, rare, to be writing code and be explaining another part of code finished yesterday that has been on screen. In this regard, the observer may be just doing the same thing that the driver is doing, fixing his eyeballs on what the driver is typing and narrowly thinking about the code on the screen. Anything not on the screen will be out of mind!

Of course, this kind of pair programming is not good for design by code. In spite of this, not many programmers can watch the lines on screen but at the same time see a wider picture and strategically think and quest for better ways. In fact, this has nothing to do with their programming capabilities! If we cannot help paired programmers do a better job of pair design, for some paired programmers, design is dead!

Bring pen and paper with you (Figure 5.17). This is our advice. The partner now is more than watching. He will still look at the screen but can now jot points down and sketch a flowchart to strategically look at a bigger design picture. This is an effective way for many programmers who are not yet used to pair programming or are not good at“watch code and think design.”

FIGURE 5.17 Bring your pencil and paper with you to pair.

PAIR PROGRAMMING IS MORE THAN PROGRAMMING 157

5.4.3 Rhythmic Pair Programming

Well, it seems a bit odd as we have one subsection in this chapter to discuss development rhythms. With a good understanding of what pair program- ming is, we will have few difficulties adopting pair programming rhythmi- cally. Moreover, software development rhythms are not practices; they reveal when the practices work and when they are used so that the practices deliver value to programmers and software writing in the workplace.

Now let us consider two situations: a team that has just one pair so that the pair cannot exchange its partner, which is referred to as “single pair programming,”and a team that has more than one pair, which is referred to as“team pair programming.”In fact, team pair programming can become single pair programming when no pair in a team decides to exchange partners.

As for single pair programming, there is no partner exchange, only role exchange. When to exchange role in a pair is less critical as two programmers are working closely together. Either of two programmers in a pair may volunteer to assume a particular role. According to one study, we have a higher length of concentration in the first 30–60 minutes while just listening and watching. Thus, every time a pair has a short tea break, they should consider changing their roles. However, changing roles has nothing to do with the problem that the pair is working on. The pair is still collaborating on the same programming task before or after their roles are exchanged. When the pair has fully shared their ideas and figured out a good solution (i.e., when there is no need to think of an alternative), the driver will be just watching how her partner writes code. Therefore, single pair programming is easy to start but not easy to sustain (see Figure 5.18).

Easy-to- sustain Difficult-

sustainto- Easy-to-

start Difficult- to-start

Single Pair Programming

FIGURE 5.18 Pair programming for a team that has only two programmers.

158 PAIR PROGRAMMING

In contrast to single pair programming, team pair programming allows pairs to rotate their partners. In this situation, some programmers will have to think out and work on new problems. As discussed in Section 5.3.5, there is some variation in the productivity effects in pairs that can make their own judgments on how to organize their work. Two and four is unknown. The right timing of partner changes is very important. If we have not rotated the partner for some time, we will simply find ourselves back again with single pair programming. Therefore, to ensure team pair programming productivity, more guidelines should be explicitly given to less experienced, paired teams, in particular, on when to change partners. We do not expect less experienced programmers to organize and do pair programming by themselves.

Pair programming is a way to achieve design by code. The moment a pair has reached a rough design, they should consider partner rotation. This maximizes our chance to let other team members improve our design, thereby removing design defects as early as possible.

A pair that is ready for a partner exchange may have to wait for another pair to be ready. Then, the pair calls for a partner exchange (CPE) by showing a sign card (or a flag, etc.) to the other pair. The idea of signaling to other colleagues or parties where we are is similar tokanban,7which is the means through which just-in-time (JIT) and “lean” manufacturing are managed.

Next, any other pair that has roughly planned out what it will do for its task and is about to exchange partners will rotate its partner with a pair with a sign card displayed (see Figure 5.19).

Often, we may change an agreed-on rough design with a new partner.

Once that happens, we have to call our previous partner (CPX) to confirm the

A B C D E F

A B C D E F

A E C D B F

A E C D B F

A E C B D F

A E C B D F

A E C B D F

A B C D E F

Call for partner exchange (CPE) Call for partner “X” (CPX)

Time

B B

X

FIGURE 5.19 Walk along time to see the rhythm of partner exchange.

7Kanbanis a Japanese word meaning a mechanism using story cards to signal the need for a particular item.

PAIR PROGRAMMING IS MORE THAN PROGRAMMING 159

change (see Figure 5.19). There can also be a situation where two partners agree on the design but a third partner does not. However, your coding should have almost done a lot. Depending on how good the third partner’s idea may be, we may either discard the existing code or discuss it in a standup meeting.

If you walk through spacetime, you will see how CPE and CPX interplay in Figure 5.19! Although the diagram looks complicated, the rhythm is simple (Figure 5.20).

Rhythmic pair programming tells us to exchange a partner when a pair has reached a rough design and call for an ex-partner exchange when a pair has revised what has been agreed to by the ex-partner.

This rhythm is good for small software teams and only for team pair programming. When the teams become familiar with this rhythm, it is not necessary to use any sign cards, nor is there any need to mechanically play out the rhythm. Many experienced pairs will know when they should change their partners and when they should pair off with their old buddies again. Rhythmic pair programming is easy to start and easy to sustain (see Figure 5.21).

FIGURE 5.20 Rhythmic pair programming.

Easy-to- sustain Difficult-

sustainto- Easy-to-

start Difficult- to-start Rhythmic

Pair Programming

FIGURE 5.21 In–out diagram for rhythmic pair programming.

160 PAIR PROGRAMMING