Constraints

Since Coderetreat has started, facilitators have been coming up with activities, constraints, or challenges to give to groups during a coderetreat. However, if you are a new facilitator, you might not know what activities to use when. This page contains a catalog of activities.

Most of the activities documented here are designed to help participants think about writing code differently than they would otherwise. Every activity has a specific learning goal in mind.

You should not feel that the list below are the only activities you can try at a coderetreat. You are welcome and encouraged to find challenges which best meet the needs of the group you are facilitating. In fact, you do not have to use any of the activities presented here.

Pairing Constraints

  • Strong-Style Pairing: The person at the keyboard (Driver) types the code. The person who is not at the keyboard (Navigator) makes all code design decisions. The Navigator instructs the Driver to implement their intent with the highest level of abstraction that the Driver can fluently work with. Driver and Navigator switch on a fixed boundary (eg: 2-5 minute timer, or completing code to make test pass)
  • Ping-Pong: One pair partner writes the test (Test-First code!), the other implements the code to make the test pass. With this pattern, with one partner may write all the tests, or the partners may take turns.
  • Mute Ping-Pong: Similar as Ping-Pong, but one partner will only be writing tests, and the other will be only writing the code to make the test pass. The pair may not to discuss or communicate about the problem in any way other than through the code (no comments, etc.: Follow the intent!)
  • Ball-Board: One partner controls the mouse, but may not type any code. Other partner controls the keyboard, but is not allowed to use any cursor navigation or hot-key shortcuts.
  • Mobbing: Group of three or more people, with Driver and Navigator roles rotating. Partners who are not Driver or Navigator suggest problem strategies and answer questions from Navigator.

Test-Driven Development Constraints

  • Lazy Coder (Use with Ping-Pong): The Driver actively tries to use the least amount of code to make a test pass. This helps guide test construction strategies and build minimal code.
  • Evil Coder (aka “Adversarial Coder”,”Find the Loophole”) (Use with Ping-Pong): The Driver is antagonistic: They will implement the code that makes the test pass, but may introduce as much complexity into the code as they wish or choose an obscure implementation strategy. This helps guide expressive test intent. (Evil Coder combined with Mute Ping-Pong is a very advanced activity, but can be extremely fun for experienced coders.)
  • TDD As If You Meant It (blog post): All code must only be written in the test. The only way to create production code is through refactoring (via Extract Method/Class/Field/Variable, etc). This creates very tight, minimal production code.
  • Test-and-Commit-or-Revert (aka Baby Steps): (Requires source control) Every pair has their own timer. They set it for 5 minutes. They have 5 minutes to write the test and make the code pass. If the test code is green when the timer expires, they may commit the code. If the tests are not passing then they must revert the code to the last green state (effectively deleting 5 minutes worth of work). Pairs may also choose to use the interval for refactoring, but the same rule applies: Failure to refactor to green in time requires a revert.
  • Steeplechase: Like Test-and-Commit-or-Revert, but the timer interval gets progressively shorter throughout the session. (eg. start at 5 minutes, but shrinks to 2 minutes by the end of the session.) Not for the faint of heart.

Development Tool Constraints

  • No Mouse: Not allowed to touch the mouse (might need to use it at first to discover the right keystroke shortcuts)
  • Text editor only: Do not use an integrated environment, only a pain text editor and command-line compiler. This helps expose how much a developer really knows about their language syntax, and can highlight how IDE features accelerate development (syntax highlighting, auto-completion, refactoring, etc)
  • Paper only: Developers write and simulate all code without a computer. Very useful for understanding the problem domain (Game of Life) and exploring design strategies or language fluency.

Programming Language Constraints

  • No Primitives: All methods (other than constructors) must take classes as arguments. Bare integers, strings, etc are not permitted. Advanced: Try to avoid any primitives as return values (This makes predicate test methods more challenging!)
  • No conditional statements: No if/switch/while/loop statements permitted. Coders may explore decision-control though polymorphism or lookup structures (control arrays, hash tables, list comprehension, etc)
  • Imperative Programming (aka “tell don’t ask” style): No method may return a value (every method must be void): This can be very challenging as many coders have not been exposed to languages that use callback methods or pass-by-reference modification.
  • Immutable Code (aka Functional Programming style): Once a memory location (“variable”) value has been set, it may not be modified. All methods are effectively stateless. (There may need to one or two exceptions in the main body of the program for some languages, but encourage the coder to avoid them.)

Software Design Legibility Constraints

  • Short methods: Limit the number of statements permitted for a function. For terse languages (Python, etc), this can be a little as 3 lines. For more verbose languages (C++, Java), five are permitted.
  • No Sawtooth: No more than one level of indentation per method
  • Literate Programming: Write you code read as if it were proper sentences. (“Let the code be read as if it was a small story.”)
  • Code Swap: Instead of deleting code, the pairs swap code with another pair for the next iteration! This activity might be challenging, depending on how comfortable the group is with multiple programming languages.

Software Problem Domain Constraints

  • Build Different Feature: If pair has written code top-down, have them try bottom-up. If they worked on rules previously, have them try building the grid or time-stepping, etc.
  • Mid-iteration Requirements Change: After 25-30 minutes, pause the group, and add an additional requirement that may work contrary to the code they may have already built. Examples:
    • Zombies: Once a cell dies and then comes back alive, it returns as a zombie and can never be killed again.
    • Live cells are colored: When born, takes on the color of the majority of its neighbors. (Three-way ties are a neutral color.)
    • Hexagonal grid instead of squares: (6 neighbors, switch rules to B2/S34 instead of B3/S23)
    • 3D space instead of 2D grid: (26 neighbors, switch rules to B4/S4 instead of B3/S23)

Videos

Adversarial Ping Pong
by Mike Gardiner (01:05)
Baby Steps
by Toni Tassani (00:38)
Code Swap Part 1
by Peter Aitken (00:35)
Code Swap Part 2
by Alan Gardner (00:53)
Mixed Constraints
by Jesse Wolgamott (01:04)
Mute Ping Pong
by Ray Grasso (00:59)
No Conditional Statements
by Manuel Kiessling (00:28)
No Return Values
by Joseph Yao (00:42)
Verbs Instead of Nouns
by Miha Filej (00:27)

Look at this exhaustive collection of constraints by Adrian Bolboaca