Subscribe to EDN

Robust Design: Sandbox Principle

April 5, 2010

Before diving deeper into the fault tolerance robust design principle, I will present three other robust design principles. This post will address what I call the Sandbox principle; although, I have heard other people use the term walled garden in a similar fashion.

Sandbox in this context refers to my experience as a parent of small children playing at the park. The park was large and there were plenty of dangers to watch out for (including rattlesnakes), but when the children were playing in the sandbox area, it felt like the urgency of protecting the children eased up a bit. The environment was reasonably well controlled and the sandbox was designed to minimize the types and severity of injuries that could occur while in the sandbox.

Apple products seem to favor the sandbox design principle to great success. For example, the Mac OS’ graphical interface constrains what kind of requests a user can make of the system. You cannot make the system do anything that the graphical interface does not explicitly support; this in turn enables Apple to tout that they are more reliable and stable than Windows systems despite the fact that the Windows system enables users more options in how to specify a task request. In this case, fewer choices contribute to higher reliability.

The iPhone implements constraints that contribute to stability and suggest a bias towards static and deterministic operations. For example, you can only open eight web documents  in Safari at a time on a second generation iPhone –as if the web pages are held in fixed, statically allocated buffers. If you never need more than eight web documents open at once, this limit will not affect you except to contribute to more predictable behavior of the overall system. If you need more than eight web pages open at once, you will need to find a work around using bookmarks as temporary page holders.

The iPad does not support Adobe Flash Player. Morgan Adams shares an interesting perspective on why this is so:

 “Current Flash sites could never be made work well on any touchscreen device, and this cannot be solved by Apple, Adobe, or magical new hardware. That’s not because of slow mobile performance, battery drain or crashes. It’s because of the hover or mouseover problem.”

This statement and accompanying details supports the sandbox principle of limiting the system options to ensure an optimal experience and reducing the complexity that would be required to handle degraded operating scenarios.

Lastly, Apple’s constraints on how to replace the batteries for the iPhone and iPad minimize the risk of the end user using inappropriate batteries and equipment. This helps control the risk of exploding batteries. The new iPad has a “Not charging” message when the charging source on the USB port is inappropriate. This suggests there is a smart controller in the charging circuit that evaluates the charging source and refuses to route the charge to the battery if it is insufficient (and possibly too fast or high a charge scenario – but I am speculating at this moment). This is a similar approach to how we implemented a battery charger/controller for an aircraft project I worked on. This is yet another example of high reliability techniques finding their way into consumer products.

Do you have any comments on this robust design principle? What are some other examples of products that employ the sandbox design principle?

 

To make following this series easier (especially as multiple series overlap each other), I am including the index below to previous posts. I encourage you to read all of the posts for the robust design series; maybe they will inspire you to share your observations. I would love to be able to consolidate different perspectives and lessons learned with regards to robust design practices here. I suspect there are some valuable lessons to be gleaned from comparing such stories. If you would like to participate in a guest post, please contact me.

Previous post in the Robust Design series:

2010, March 29: Robust Design: Fault Tolerance

2010, March 22: Robust Design: Ambiguity and Uncertainty

2010, March 15: Robust Design: Best Guesses

2010, February 10: Robust Design : Good, Fast, Cheap – pick two

2010, February   4: Robust Design

 

Posted by Robert Cravotta on April 5, 2010 | Comments (4)

April 14, 2010
In response to: Robust Design: Sandbox Principle
Dale Shpak commented:

The sandbox is a fundamental architectural paradigm that can be used to greatly improve reliability, maintainability, testability, and portability at the expense of flexibility and possibly speed. Most often, the benefits far outweigh the costs, especially when life-cycle costs are considered. It is also a way to manage complexity in large systems. A similar concept is a closed hierarchical or layered architecture where components can only access the adjacent layers -> no direct access across multiple layers. For example, consider the TCP/IP stack, where, when correctly implemented, you can replace any number of layers and still have correct operation. And the developer of the new layers needs only to consider the adjacent layers ... no hunting through a huge code base to find and consider every usage! Strong encapsulation is always a good idea, regardless of the language or hardware architecture. If it looks like spaghetti on a UML diagram, think again!


April 14, 2010
In response to: Robust Design: Sandbox Principle
Dale Shpak commented:

The sandbox is a fundamental architectural paradigm that can be used to greatly improve reliability, maintainability, testability, and portability at the expense of flexibility and possibly speed. Most often, the benefits far outweigh the costs, especially when life-cycle costs are considered. It is also a way to manage complexity in large systems. A similar concept is a closed hierarchical or layered architecture where components can only access the adjacent layers -> no direct access across multiple layers. For example, consider the TCP/IP stack, where, when correctly implemented, you can replace any number of layers and still have correct operation. And the developer of the new layers needs only to consider the adjacent layers ... no hunting through a huge code base to find and consider every usage! Strong encapsulation is always a good idea, regardless of the language or hardware architecture. If it looks like spaghetti on a UML diagram, think again!


April 8, 2010
In response to: Robust Design: Sandbox Principle
William Ketel commented:

You are correct in that windows offers a few more possible actions than the Mac OS. BUT windows is grossly inferior to any of the DOS operating systems as far as offering the ability to do things other than what somebody else decides is all that I need to do. It really is similar to the concept, in the book "1984", where the language was redesigned to avoid "badthink". The windows OS is similar in that it has chosen to allow choices in truly worthless areas like wallpaper and screen savers and icons, while assuring that the files that we create are all stored in an area called "my documents, assuring that any hacker who wishes to do damage, or hold them hostage, is aware of exactly where they are located. Likewise, anybody who breaks into my computer knows exactly where to look to find my personal files. So tell me this: how has limiting my options improved this product. So it is true that by limiting the ability of a product to do things, it is indeed possible to create a product that can only do one thing adequately.


April 8, 2010
In response to: Robust Design: Sandbox Principle
William Ketel commented:

You are correct in that windows offers a few more possible actions than the Mac OS. BUT windows is grossly inferior to any of the DOS operating systems as far as offering the ability to do things other than what somebody else decides is all that I need to do. It really is similar to the concept, in the book "1984", where the language was redesigned to avoid "badthink". The windows OS is similar in that it has chosen to allow choices in truly worthless areas like wallpaper and screen savers and icons, while assuring that the files that we create are all stored in an area called "my documents, assuring that any hacker who wishes to do damage, or hold them hostage, is aware of exactly where they are located. Likewise, anybody who breaks into my computer knows exactly where to look to find my personal files. So tell me this: how has limiting my options improved this product. So it is true that by limiting the ability of a product to do things, it is indeed possible to create a product that can only do one thing adequately.

POST A COMMENT
Display Name
captcha

Before submitting this form, please type the characters displayed above. Note the letters are case sensitive:

Advertisement
Advertisement
Advertisement
About EDN   |   Site Map   |   Contact Us   |   Subscription   |   RSS
© 2012 UBM Electronics. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy

Please visit these other UBM Canon sites

UBM Canon | Design News | Test & Measurement World | Packaging Digest | EDN | Qmed | Pharmalive | Appliance Magazine | Plastics Today | Powder Bulk Solids | Canon Trade Shows