Cross-functional pair programming -

Cross-functional pair programming

Pair programming has a special application to embedded systems development. When hardware engineers work with software engineers the result is increased productivity and better code.

To enhance the software development process, agile software development methodologies often include the practice of pair programming—two software engineers developing software together. This article describes an alternative type of pair programming aimed at embedded systems development that I call cross-functional pair programming (CFPP). Rather than combining two software engineers, CFPP combines one software engineer with one hardware engineer. If properly managed, the gains in problem solving ability, productivity and product quality can be impressive.

Traditional pair programming
Pair programming can be defined as two software engineers working together to create software. The pair may create any artifact of the software development process—a diagram on a white board, a test case, a high-level software design, a relational database schema, a tricky bit of optimized code. The point is that they work together as a pair, sharing resources. And not only do they share physical resources (such as a white board or computer), but more importantly, they share mental resources. Two heads are better than one, and four eyes are better than two, as they say.

Of course, only one person at a time can actually work the mouse or keyboard (although sometimes two can even do that), so each member of the pair must take turns. One acts as the pilot, actually working the keyboard while the other acts as the copilot, carefully watching and considering the work of the other. The roles of pilot and copilot are deliberately switched in order to afford each person equal time in each role.

Each person in the pair is considered an equal participant in the process and each has equal ownership of the results.

Those keeping up with current developments in software engineering have no doubt heard of pair programming in the context of eXtreme Programming (XP). Indeed, pair programming sits at the very center of XP. However, keep in mind that XP is a much bigger topic. XP is a holistic approach to developing software. Some of the many concepts in XP also include user stories, an iteration plan, stand-up meetings, refactoring, CRC cards, continuous integration, which are all beyond the scope of this article. Suffice it to say that XP has wholeheartedly adopted pair programming.

A definition of pair programming I particularly like comes from Kent Beck's book Extreme Programming Explained: Embrace Change :

“One partner, the one with the keyboard and the mouse, is thinking about the best way to implement this method right here. The other partner is thinking more strategically:

  • Is the whole approach going to work?
  • What are some other test cases that might not work yet?
  • Is there some way to simplify the whole system so the current problem disappears?”1

Those with many years of experience actually delivering working code and getting things done may have delved into pair programming before it even had a name. Back in the mid-1990s another software engineer and I were given an assignment to develop some software for a handheld computer. Since the GUI-building tool we were using required us to create one monolithic source-code file, we decided to work together at one computer. I must admit I felt a bit guilty working as a pair, and our supervisor cast a few doubting glances our way in the beginning. But in the end we created and shipped a high-quality software application, on time, to a satisfied customer. I enjoyed the project—in spite of my guilt. However, having been brought up to believe that programmers work alone, so I was relieved to get back to my own computer.

Pair programming was formally identified in the mid-1990s. In his 1995 book, Constantine on Peopleware , Larry Constantine introduced the term “Dynamic Duos.”2 Also in 1995, Jim Coplien discussed the “Developing in Pairs” pattern in the book Pattern Languages of Program Design .3

Pair programming has been put to the test and shown to be beneficial. In “The Costs and Benefits of Pair Programming,” Alistair Cockburn and Laurie Williams found that “for a development-time cost of about 15%, pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable at statistically significant levels.”4 Laurie Williams and coauthors concluded in a separate article that “the research reveals that through pair-programming, software products can be produced in less time, with higher quality.”5

Cross-functional pairs
As I mentioned earlier, cross-functional pair programming (CFPP) is a variation on the theme of pair programming and is specifically aimed at the development of embedded systems. Since CFPP is meant to be pragmatic and effective, I don't propose a direct analog to pair programming. Rather, I take what is appropriate from pair programming making modifications as needed.

CFPP is defined as one software engineer working together with one hardware engineer to create all or part of an embedded system.

By their very nature, embedded systems include both software (some might say firmware) and hardware. Since embedded systems include both software and hardware, it seems natural to say that a pair working on an embedded system should have rich skills in both software and in hardware.

The ideal pair for CFPP includes a software engineer who has some knowledge of hardware and a hardware engineer who has some knowledge of software. There must be some overlap in the skills and knowledge of the pair as demonstrated in Figure 1, but each must have good expertise in their field.

Figure 1: Cross-functional pair programming team

The pair works together much as in traditional pair programming. While one works the tools of the trade, the other carefully watches and considers the work of the first. One major difference in CFPP is that the tools are shared much less, for a simple reason. In pair programming, each person is, more or less, equally skilled with the tools (for example, the computer, the white board). In CFPP, however, there is a much smaller set of shared tools. The switch of roles from pilot to copilot usually involves a switch of tools. The software engineer's tools (such as programming/debugging tools, in-circuit emulators) are aimed at creating software. The hardware engineer's tools (such as hardware layout tools, soldering irons) are aimed at creating hardware. The tools most often shared include a white board, a computer, an oscilloscope, or a logic analyzer. Moreover, role switches are driven more by the current needs of the project than the need for equal time in each role.

Since the overlap of skills and knowledge is reduced, the copilot's role in CFPP is not quite the same as it is in pair programming. In CFPP, the copilot tends to ask more “obvious” questions. However, in my experience, answering these “obvious” questions often clarifies the pilot's view of the system and how best to proceed. It must be stressed, though, that the overlap of skills and knowledge must be significant enough so that the pair can communicate effectively no matter who is the pilot.

CFPP includes more time spent working alone (or in a traditional pair) when a lot of specialized work needs to be done. For example, hardware changes need to be made and the pair has agreed on the changes, the hardware engineer is usually better off making those changes on his own (for it may be too difficult for the software engineer to copilot such specialized work). Of course, once the changes are completed, the pair reunites to test the modified system.

The pair must be included in (or at least kept informed of) all phases of project development. For example, it's important to include the software engineer during high-level hardware design—a software-oriented viewpoint may affect the choice of hardware (such as type of microcontroller, amount of code space, amount of EEPROM).

As in pair programming, the most important shared resources in CFPP are the mental ones. And, as before, each person in the pair is considered an equal participant in the process and each has equal ownership of the results.

The main benefits of cross-functional pair programming are increased problem solving ability, increased productivity, and higher product quality.

In my experience, a CFPP pair is more than the sum of its parts. The two skill sets compliment each other nicely, creating a synergy. The pair's ability to solve problems is greatly enhanced (compared to each person alone) by the nature of the collaboration.

For the reasons stated above, CFPP increases productivity. This is so because embedded-systems development requires software and hardware personnel, and CFPP is a more efficient way to work—communication is increased, problem solving is better, and the desired result is arrived at sooner.

Another benefit is higher product quality. As in traditional pair programming, when two people work as a pair, reviewing and checking each other's work, less mistakes are made and better decisions are taken. Problems are solved from a more inclusive viewpoint and fewer “short cuts” are taken. All this usually results in higher quality work.

Cross-functional pair programming is not appropriate in all scenarios and does have certain pitfalls. The main things to watch out for are the wrong type of project, mismatched pairs, and incorrect use of pair-time versus individual-time.

As stated previously, CFPP pairs work best on embedded-systems projects. However, the benefits of CFPP are maximized when the embedded system includes new or previously unused hardware. If the embedded system is based upon a well-known hardware platform it may not pay off to use CFPP because many of the difficult hardware/software problems have already been resolved. On the other hand, a new or previously unused hardware platform almost always has a learning curve, and that's where CFPP shines.

CFPP benefits may suffer if the pair is mismatched. If the overlap of skills and knowledge is too great or too small, the effectiveness of the pair is reduced. As described previously, each person must have some knowledge of the other's field and expertise in their own field. Unfortunately, there aren't any hard-and-fast rules—for now, matching up an ideal pair is more of an intuitive art than a science.

Another potential pitfall to CFPP is the incorrect use of pair-time versus individual-time. CFPP requires that the pair separate more often than in traditional pair programming. Each person may encounter significant stretches of time when their expertise is needed and the other partner can't effectively act as copilot. It's important for the pair to recognize when pair-time is appropriate and when individual-time is appropriate. Note that individual-time may entail traditional pair programming.

Managing these pairs
Managing cross-functional programming pairs consists mainly of helping each pair maximize the benefits of CFPP by minimizing the pitfalls of CFPP. The manager should maximize the increased problem-solving ability, increased productivity, and higher product quality by minimizing the wrong type of project, mismatched pairs, and incorrect use of pair-time versus individual-time.

The manager must carefully select which projects may benefit from CFPP and which may not. As described earlier, a new or previously unused hardware platform usually flags a project appropriate for CFPP. Moreover, the manager may need to assign multiple pairs to the project and divide the work appropriately among the pairs.

Except for the general guidelines I've presented, there are no hard-and-fast rules for who to pair with whom. Dive in, form some pairs, and see what works.

Once he or she has selected an appropriate project and formed some pairs, the manager must help the pairs understand when to work together and when to work apart. Ideally, this is a skill that the pair will develop so they can spontaneously use their time to best advantage. Note that working apart may entail traditional pair programming (in other words, pairing with an engineer from the same field in order to engage in specialized work).

These management skills must be added to the “normal” set of skills needed to manage embedded-systems projects.

In sum
CFPP has a more free-flowing nature than traditional pair programming. Work may be done in CFPP pairs, in traditional pairs, or individually—the nature of the work dictates what's appropriate. Also, the role of pilot and copilot depend more on the current needs of the project rather than the need for equal time in each role.

The main benefits of cross-functional pair programming are increased problem solving ability, increased productivity, and higher product quality.

The main pitfalls of cross-functional pair programming are the wrong type of project, mismatched pairs, and incorrect use of pair-time versus individual-time.

By minimizing the pitfalls of CFPP, the manager can maximize the benefits of CFPP.

Future needs
Cross-functional pair programming is based on the success of pair programming and on some of my own observations. None of the benefits of CFPP have been rigorously tested—my evidence is currently anecdotal.

Future needs include rigorous testing to expose where and when CFPP is most effective. Also wanting is a clearer definition of the skill sets of the pair and perhaps a definition of ideal sets of skill sets for different types of embedded-systems projects.

The challenge goes out to the current crop of graduate students to fill these future needs. esp

James E. Hewson holds a BSCS and has 15 years experience developing embedded-systems software and PC software. James currently works at Bellatrix Systems. He can be reached via e-mail at .

End notes
1. Beck, Kent. Extreme Programming Explained: Embrace Change , Reading, MA: Addison-Wesley, 2000.
2. Constantine, Larry. Constantine on Peopleware , Englewood Cliffs, NJ: Prentice Hall/Yourdon Press, 1995.
3. Coplien, James O. and Douglas C. Schmidt, Ed., Pattern Languages of Program Design , Reading, MA: Addison-Wesley, 1995.
4. Cockburn, Alistair and Laurie Williams. “The Costs and Benefits of Pair Programming,” Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000) , 2000.
5. Williams, Laurie, Robert Kessler, Ward Cunningham, and Ron Jeffries, “Strengthening the Case for Pair-Programming,” IEEE Software , July/August, 2000.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.