Hardware Reference
In-Depth Information
product would be easier to hack, but the complexity had to go
somewhere.
More room to hack means more room for users to make mis-
takes, and that has major implications for customer support. We
understood, in the abstract at least, that a sense of accomplish-
ment in hacking really comes about only when you've success-
fully done something that you
could have
screwed up. Now that
we've shipped our products, we truly understand this point:
people will screw things up.
(And that's great! That's how we
learn!) And they will ask us for help often (as they should). We
have to be ready to help with the depth and breadth of
troubleshooting that individual customers need.
It is useful to document and post each customer's troubleshoot-
ing advice as a resource for everyone else. Anyone hoping to re-
lease a hackable product to more than a handful of experts should
recognize how absolutely crucial good customer support and
community management will be to the end user's experien-
ce—and how much work it is to provide.
None of this is intended to discourage people from building modular,
hackable hardware. In the end, design is about working within and
around constraints. We chose to accept the constraints of creating a
hackable product, and it turned out to be a really interesting design
problem. Now we're sharing some of the challenges we encountered so
more people can anticipate what they'll be—because even with the dif-
ficulties, we still think it's worth doing!
Summary
Some years ago, NASA did a nice study called “Error Cost Escalation through the Project
eye-opening look at how much it costs to fix your mistakes the closer you get to shipping
your product. NASA discovered that errors caught in the final stage of a project can cost
more than 1500 times more to fix than errors caught before design begins. Giving an extra
few hoursofthought toyourproduct specification could save youtens orhundreds ofthou-
sands of dollars later in the project. The bottom line is, catch your errors early and often.
