Duet Programming
Duet programming is a protocol for collaborative programming that provides
structure and organization for computer science learners. The purpose is
to define roles that allow both students to actively engage in the
design and implementation process at all times, albeit on different aspects
of the same program.
This is accomplished through division between core implementation and test
code. By taking a test-driven development approach, the design and
implementation of test cases is given equal weight to the design and
implementation of the core functionality of the project. Students are
expected to trade off between testing and core implementation often for
large projects in order to make sure that they both engage in both
parts.
This protocol has been created to address a disadvantage of Pair Programming,
the dominant protocol for collaborative computer science learning. In that
protocol, only one person actively develops at a time (the driver), with
the second member assisting when necessary (the navigator).
This protocol can make it difficult for the navigator to stay engaged.
There are two main aspects to collaborative work. The first is how to
communicate with each other respectfully and constructively in order to
provide a supportive learning environment.
The second is to follow specific protocols that provide
phases of working independently and working together
in order to build skills towards completing software development entirely
independently.
Maintaining a supportive learning environment
Do:
-
communicate when either partner has questions, even if it is during the
independent work phases.
-
isten to your partner, especially when he/she has different ideas than
you do. There are many correct answers in programming - the interesting part
is exploring the advantages and disadvantages of different decisions. So ask
the other person why they did something before suggesting an alternative.
Together understand what the tradeoffs are and choose the best solution (if
a different solution is actually better - do not quibble over equivalent
solutions).
-
Rotate roles often. Once problems get sufficiently large, make sure you cut
them up into pieces. Switch roles for each piece.
-
Be patient. Different ideas are normal, and some students have more difficulty
communicating the ideas and reasons behind them than others. Do not mistake
quality of argument for quality of solution. Think about ways your partner is
correct rather than jumping to conclusions. Ask questions when you disagree.
-
Respect your partner. Everyone at U of Chicago has earned academic respect
by being accepted to this university. Even if you have more experience than
your partner, the purpose of these activities is to learn, not to be correct.
Respect your partner's ideas and provide positive feedback when merited, even
if you might have an idea you think is better.
-
Take breaks. If you work too long, you will be more easily frustrated, and you
might accidentally take that frustration out on your partner. You should not
work for more than an hour without a break.
-
Prepare. Make sure you have attended class and/or read the relevant resources
so that your partner does not need to teach you what you should have already
seen.
-
Practice good hygiene. This includes showering daily, wearing deodorant, and
wearing laundered clothing. Different cultures have different practices, but
when working in close physical proximity, it is important to be mindful of
local practices.
-
Have fun. Don't be afraid to make jokes, unless they could be interpreted
as insulting to the other person.
Don't:
-
control the other person. Make sure that each person has the chance to
explore solutions, even if they do not match your solution. If you are
making suggestions about what code the other partner produces, be very careful
that your ideas are enough better to merit the suggestion. It's important
that each student be able to try their ideas and get feedback from the system.
If you impose your ideas on your partner, you are robbing him/her of that
important learning opportunity.
-
be intimidated. Some of the material is quite challenging, which is what
partners are for. All of the material is chosen to match your experience.
-
be quiet. Yes, you should allow for independent work periods. But if you
have a question, that's what the collaboration is all about!
-
suffer in silence. If there are issues in your collaborative partnership,
please speak with an instructor to help resolve them. This experience should
enhance your learning, not detract from it.
Duet Programming Protocol
Duet Programming is divided into three phases. Each phases begins with
independent working and ends with a discussion. The second two phases may
be repeated, with the two partners switching roles each iteration.
From a high level, partner A will be the functionality developer, and
partner B will be the test developer.
Phase 1: Problem Clarification, test design
Student A: Determine exact interfaces for functions. Implement the
"skeleton" files - main, .h, and .c files. These files must compile and
include all of the functions you will implement. For all functions, they
will contain a single line that returns an item of the right type (if they
are supposed to return something).
Student B: Identify input ranges, (valid inputs and non-valid inputs with
borders), identify which inputs should be test cases and their expected results.
Categorize test cases as "normal," "boundary," or "error."
These tests are called black box tests because you know only the
interfaces, not the actual code, when you design them.
Discussion: Both students inspect the others' work. They ask any
questions when they are unsure, suggest more test cases if applicable.
Divide the functions into groups and order them in the order in which you
will implement them. Execute phase 2 and 3 separately for each group of
functions, trading off between roles.
Phase 2: Implementation
Student A: Implement the first group of functions (in the .c file).
Student B: Implement the tests for the first group of functions. Do not
forget to use good modularity when designing your test code.
Discussion part 1: Look input ranges from the black box tests. Is there
separate code to handle each case? If not, are the different ranges equivalent?
Also, verify that the boundaries in the input ranges match the boundaries
present in the code.
Discussion part 2: Looking at student A's code, jointly develop a set of
white box tests that exercise all paths in the code. If you developed
more tests than the black box tests, discuss whether that code is necessary,
or whether the initial tests were insufficient.
Phase 3: Compilation and testing
This phase is performed together.
First remove any compilation errors.
Then execute the test cases. Discuss and jointly correct any bugs.
Once you have completed phases 2 and 3 for a group of functions, switch roles
and repeat!