Note: This was written as a reminder for instructors, who are already familiar with these techniques, to refer to while advising students. It is long on general advice and short on examples. It may be useful to students as well, who are willing to put some work into reading it and are willing to then check with an instructor or other advisor (such as a more experienced student) once they have a tentative plan.

Note: Some of this advice applies to projects, or engineering projects, or software projects, in general. Some of it is specific to physical computing or the Arduino.

Alternatives for how students can work together remotely:

• Divide the project into pieces (components); each do some of them. There’s an art to dividing a project into pieces that can be done separately, and it’s especially difficult if you haven’t done a lot of projects before. There’s more on this below, but it’s good to run your work plan proposal by an instructor or other advisor.
• Use collaboration tools, so that you can work on the same component together on one screen. See the section below, on Collaborating on Code.
• It’s often nice to combine these techniques and/or switch back and forth between them. For example, work on a component alone while your partner works on another component, but switch to working on the same thing together: if one of you gets stuck, or to give each other feedback and fresh ideas, or to make sure both of you get more learning out of the project.

Separating a project into components

• A larger project can be broken down into an ordered list of tasks. Each person takes a new task from the list, when they’ve completed the one they were working on.
• An easy way to divide a project is by fabrication technique; for example, code vs circuit vs fabrication of housing or enclosure, etc. This may be enough, especially with a short project and a small team, and if you have distinct learning objectives (you aren’t both trying to learn about coding, and you aren’t both being assessed on coding).
• If your project has stages or levels (it offers one set of interactions and behaviors at one time, and another at a different time), sometimes each stage can be developed as a separate component. (If the stages have common functionality, this requires a different technique or extra coordination. For example, this technique wouldn’t be useful for the initial development of a platform game, where the levels differ only in the arrangement of walls and obstacles.)
• During development, it is common to stub a piece of functionality – use a stand-in that is much easier to build, even if it doesn’t have the required functionality or fit or polish. This is especially helpful when dividing a project.
• Figuring out how to divide a project into components, in order to plan the fabrication, is itself work. A lot of it is work that you would have to do at some point anyway, in order to perform the fabrication. If you haven’t done many projects before, you might get stuck trying to figure out how the components can be divided before you actually construct the components. Recognize the limits of this approach; and that these limits might be different for your second or fifth or tenth project than for your first.

Separating an Arduino Sketch

Thoughts on dividing the coding part of an Arduino project into pieces:

• If the sketch can be divided into pieces that use different physical components (different sensors and/or outputs), one student can work on the code that uses one sensor or output, and the other on code that uses another sensor or output
• You can simulate a sensor you don’t have by using a button. For example, if the device is supposed to run a fan in a certain way when the user waves their hands in front of a detector and you’re responsible for running the fan, make it happen when the sketch starts or when the user presses a button.
• You can simulate an output that you don’t have have by using an LED. For example, if the device is supposed to run a fan in a certain way when the user waves their hands in front of a detector and you’re responsible for detecting when the user has waved their hands in the right way, flash the LED into of running the fan.

Integration hell refers to the difficulty of taking separately-developed pieces and getting them to work together. If you divide up your work, it is important to frequently and early practice combining the pieces. Integration failure is the most common failure mode of a team project with separately-developed components.

Note that dividing a project into pieces is useful even if you are not forced to work remotely from your team mate. Then you can both be working on things at the same time.