Eyal Shahar - Project Reliability Engineering: Pro Skills for Next Level Maker Projects

In 2014, I took a job at the Exploratorium, the museum for science, art, and human perception in San Francisco, California a job that I am still holding at the time of writing these lines. In my role as a New Media Exhibit Developer, I am assigned to upcoming exhibitions and charged with coming up with ideas for exhibits for them that use new media elements. This means that these exhibits feature touchscreens, physical computing components, projectors, and so forth. Some of the ideas I come up with get tossed away immediately they might be too hard to make, too silly, out of the scope of the exhibition, or maybe they would just not make good exhibits but other ideas show potential. I take those ideas and make prototypes. A prototype starts with something as simple as a diagram or a paper simulation, and at some point (and usually pretty quickly) it evolves into a computer program on an Arduino, Raspberry Pi, a desktop computer, or a virtual machine. I am a sub-average fabricator, but if any physical structure is needed at this point, Ill hack something together using my favorite tools a table saw, a drill press, and a laser cutter.

A prototype is then evaluated by the project leadership and by our Visitor Research and Evaluation Department, who take the prototype to the museum floor and watch how visitors interact with it. Based on the feedback, I modify the prototype, often getting support from other departments such as the Graphics Department in designing the visual elements and the Editorial Department in refining the text content of the labels and the screens. After a few iterations of evaluation and adjustment, the exhibit is ready for production. I stabilize or sometimes completely rewrite the code, order and assemble all the parts, and ensure that the electronic circuitry complies with our standards. At that point I might get more support from our engineers and technicians in building cabinetry and manufacturing circuitry. To conclude the process, I make sure everything is documented and that the code is backed up on our servers and in the cloud.

In summary, my job is to own and shepherd the exhibit from ideation to deployment, which is what every maker does. Since this is my actual job, I guess that makes me a professional maker. Over the years, Ive learned that professional makers work in many industries. They make prototypes in design companies and corporate companies innovation teams; they create rides for theme parks and practical effects for movies and theater; they produce public art installations; and they build exhibits for science museums.

In order to make the leap from being hobbyists to professional makers, makers must add a few tools to their toolbox. Among these are the ability to create robust and reliable products and to be able to effectively monitor and control them. The exhibits that I make at the Exploratorium are used by hundreds, sometimes thousands, of people every day, and I need make sure that they work , that they overcome power outages, and that they know how to deal with edge cases without crashing. Also, the Exploratoriums footprint is pretty big just the exhibit space is about 75,000 square feet and over 800 feet from end to end. This means that I need to have a way to monitor the exhibits from my desk rather than walk repeatedly to the various galleries and back to my desk all day.

Professional makers from various industries have similar needs, and I hope this book will help them formalize their process when it comes to reliability. For makers who aspire to become professionals, the primary audience for this book, I hope this book will serve as a stepping stone as they build their new career. Finally, I believe that even hobbyists who are happy to keep creating projects just for fun will find this book valuable and eye-opening.

Here is an over-simplified history of reliability engineering: in the beginning, there were companies that made software. Development was done in stages: first, the company would analyze the market and product domain and decide on the software requirements; then the company would enter a design stage, where the Software Development team would decide upon structure and components of the software. Next, the developers set to code the actual components of the software, building and refining the product, adding features, and fixing bugs; the Quality Assurance team (QA) would then test the product, and when all was said and done, the Operations team would step in: the Operations team was mostly in charge of hardware both the companys and its clients, network hardware and configuration, data backups, and so on. It was their job to