Build and Program the Solution

This criteria area has two subsections that some teams forget to take into consideration. The first is build which is the primary area teams focus upon. The second area, program, is where teams often fall short.

Build

When considering what to include in this area there are varieties of depths that a team can explore. It can be as simple as providing some images of a subsystem or completed solution or go as far as providing step by step instructions around how to put the solution together with a full parts list down to the screws and nuts being used.

When deciding what is enough detail to provide, consider what you would need if you had to rebuild/recreate your own solution. Would you need a few sentences describing a solution with accompanying sketches or detailed CAD with a full parts list and build instructions?

---

Program

For programming teams may vary from putting in a couple functions describing key features to placing their entire code. While the latter is nice, it may be overkill for what is needed from a recreation perspective.

What is a good approach to documenting a team’s code base?

• Use Pseudocode to give the reader an understand of what is trying to be accomplished

• Create path maps to go with the Pseudocode

• Provide snippets of code and not an entire file

• Comment code, not only is it a good practice but can help the reader understand what is taking place in a particular section of a code

One consideration to keep in mind is that many teams are starting to use coding templates. As the growth of these continues to be leveraged by more and more teams, the diversity in coding and showing/explaining what is being developed for use may shrink. To show how a team is using that code or any modification or unique approach it is worthwhile to comment as much as possible or even create markups that can go alongside the code in the notebook. Additionally it is also a good idea to provide credit to the author or team of the template.