Hardware Reference
In-Depth Information
sions allow team members to do time-consuming work (such as analys-
is or drafting) on their own, then present their work and receive feed-
back. The slower pace gives everyone involved more time to process
the material being discussed and to do further work as required without
holding everyone up in a meeting.
Test early and test often. So, how do you know if a new design idea
is a good one or if it even works? For very large projects or very risky
ones, analysis is the order of the day. However, most open source hard-
ware projects are at a small-enough scale that it is far more efficient to
put a prototype together and test it. This approach of testing designs
early and often is recommended owing to the success of famous makers
like the crew at Armadillo Aerospace, who designed winning rocket-
powered landers by iteratively testing their vehicles, often to the point
of failure. The lessons learned from actual tests, especially those in-
volving failure of the system under testing conditions, proved to be in-
valuable to the Armadillo Aerospace team. The same is true for smaller
projects. Recently, a co-developer of the Holoseat (
ht-
tps://opendesignengine.net/projects/holoseat
)
suggested we could re-
place a linear potentiometer used to adjust the difficulty setting with a
desktop application in the system tray. He worked up a prototype in a
couple of hours and we tested it. The desktop application worked so
well that it not only proved the point that we didn't need the poten-
tiometer, but also led to a number of new features for the project that
we could not implement without the desktop application in the design
(such as activity tracking with badges and social media integration and
per-user configurations).
Share your failures along with your successes. I realize this recom-
mendation may be difficult to swallow. After all, we live in a world that
worships success and shies away from failure. But, consider this:
Would you rather make the same mistake everyone does when trying to
build the first open source car/boat/plane/tractor, or would you rather
learn from everyone else working on this same goal and be able to
make new mistakes (or maybe even find a working design)? The an-
swer is simple: We would all rather spend our time advancing the pro-
ject than repeating the same mistakes everyone makes. Simply put, it is
a waste of time and effort to have to rediscover what doesn't work, just
as much as—and possibly even more so—it is wasteful to have to re-
discover what does work. So, if we want to leverage the full benefit of
