[Editor's Note: This was originally posted on the Embedded Master]
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?
Tags: Sandbox Principle
Processor Tracker
All Entries RSS Feed
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.
Products are a compromise. Yes, a screwdriver tends to be a very reliable but limited and simple tool, yet, in order to cope with this simplicity I end up lugging a tool box of such simple things around. If I could opt for a ‘Dr Who sonic screwdriver’ that can undo anything and everything and drop neatly into my pocket….
Who knows, the point is that yes, a simple product is easier to make and can be more robust, a more complex product though gives its user more… theres room for both approaches.
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!