Transcriptions, III

Communication. In designing systems for others you need to make your intentions for usage known. This is sometimes called documenting the system.

You should write documentation with one target audience in mind. Then review the documentation with an eye toward rewriting it for a less savvy audience.

It is useful to write something like a theory of operation section, which gives the user some notion of what the system does and why he/she would want it to do that. Then, technical details of how can follow.

One also should consider that no one reads the documentation. Thus, appropriate blurbs should be used. (Don’t put remaining hand in grinder.) Further, the design should consider making the documentation simpler.


Constraints. They can be a good thing. In designing a system, limiting ones choices can focus the development of the design, and allow it to go more quickly. Indeed, given enough carefully chosen constraints, very few design possibilities result, and the system comes together like putting a jigsaw puzzle together.

It is good to know where constraints come from, and why. Many result from user requirements, some from the capabilities of the components, some from economic consideration. Whatever the source, it helps to know if a constraint can be removed, or relaxed. This is especially important when there are too many constraints, i.e. the limitations make it unlikely to produce a result satisfying all of the limits. It is not expected to build an ice cube maker, that, under normal conditions, produces ice cubes that are cube-shaped and warm to the touch, i.e. should be both below and above 50 degrees F at the same time.


Maintenance. How long does your system last?

For systems with physical components, it is easy to think of such systems needing occasional repair and maintenance. If well designed, such repair can be done quickly and easily. However, complex nonphysical systems
also need maintenance. A common type of example is a data storage system. In order to use less space, data may be reorganized and rearranged and rerepresented. In software, garbage collection is a type of routine used in
memory management. Systems also need updates and improving to keep up with changing demand. Thus, flexible systems can accommodate redesign and adaptations. Certain government codicils allow for such amendments.



Transcriptions II

Perspective. I stand over someone, my head 2 feet above theirs. I point to something in some bushes at my eye level. Can the other person see it?

A lot of interesting things can happen because of differences, even minor differences, in points of view. Arguments can start, ideas discovered, new systems invented. In doing a system design, some changes in perspective can be quite useful. In doing usability studies, some system designers use and watch users use the prototypes, in order to improve the performance of the system under conditions in the field. By viewing a particular problem in more than one way, the solution becomes clear.

A classic example: Plant 10 trees in 5 rows of 4 trees each. One can look at this from the perspective of 10 trees. It becomes clear that the 5 rows can’t all be parallel and so one starts placing 10 trees in various arrangements. It can take some time to arrange these trees to get 5 rows with 4 trees in each row.

Now comes the change in perspective: Instead of placing trees, try placing rows. Since some rows will intersect, you can start by choosing 5 lines, no 2 of which are parallel. When you do this, you will find the 10 points of intersection satisfy the desired conditions. Instead of hunting around for a placement of points, any line placement works.


Delegate. In dealing with large systems, it helps to forget some details, at least temporarily.

Two methods take advantage of this forgetfulness. Designing from the top down involves representing the components of the system by blocks and requirements and interrelations between the blocks, and then considering each block as a system to be designed to fit the previous requirements and interrelations. If necessary, each block can itself be broken into smaller blocks and interrelations.

The second method involves recognizing a set of primitive components, each of which can be easily designed and implemented, and then forgetting the implementation of the components and combining them in interesting ways to form larger systems.


What is success? The system you make should meet some goal, and in some cases you need to demonstrate the goal is being achieved, at least in part. So what do you do?

One strategy is design-to-test. This strategy says to create components that allow you to measure, or test, parts of the system to establish yes/no answers related to the system goals.

One such goal is reliability. Given the same conditions or stimuli, will the system give the same response? Will the system respond the same way even under environmental extremes? What limits will the system endure, or start to malfunction?

Other tests are diagnostics. If the system fails a certain test, does the failure indicate what portions need repair/replacing?

Some systems are transparent enough that all required tests can be performed externally, without the need for components specific for testing. Black box design does require at times a design-for-test philosophy.


Get ready, get set, …

I feel the need for another preface. The next set of postings are lightly edited transcriptions from notes made some years ago. They may seem like disjointed topics grouped together; they should be considered as kernels for larger essays to be developed. One intent is to be provocative: I want you to think critically about the subject and find something to add or subtract from it. The notes will be posted with a title like “Transcriptions” here. I will also include some numbers for my temporary reference. When the sdfae domains are configured, the posts will be rearranged and expanded to accommodate other goals.

I thank you for waiting and storing your feedback to give when the proper mechanisms are in place. Your patience is appreciated and I will reward it.

… go! Transcriptions I

I will show you several ways of thinking. The different ways serve different goals (masters?) and are not always compatible (agreeable?) . However, with practice, you can employ combinations of them to great effect. System Design should not be pinned down to a single philosophy or frame of reference. System Design also should not be a static collection of principles, heuristics, and rules-of-thumb. System Design should be fluid, personalized, and grow and change as you see fit. What is presented here should serve as a catalyst, prototype, and laboratory. Even if you do not create a system for yourself or others, System Design can aid your comprehension of other systems.

There are various methods by which you can acquire the skills presented here, but only two things can guarantee success: thinking about the material, and its relations to your experience; and practicing the concepts. Reading and memorizing without comprehending will not work.


What is a system? Pretty much, it is what I say it is. I will not define it for you, but I will describe some of it. A system is sometimes some arrangement of stuff that, in some sense, does something. Many things in life are systems. Some that show signs of man-made construction are philosophies, religions, governments, plans, buildings, betting protocols, recipes, algorithms for sorting, desserts, piles of paper, a book, many manufactured items, a bill of lading, receipts, notations. There are systems that are not made by man, but have some arrangement or classification imposed on them, such as sedimentation, cell structure, anatomy, life cycles, chemical reactions, crystalline arrangements, and so on. Even things that have no pattern or clear arrangement can be considered systems, such as weather, and other physical processes. Many systems involve more than one things, but not all systems. My untidy desk is a system. Someone’s scrapbook is a system. Someone else’s family tree is a system. Many of these systems will reveal, through scrutiny, how they were designed. Or, how they can be designed again.


Language is important. In attempting to convey meaning, people will set up a context, and then use abbreviations and other devices to aid in delivering information quickly, or reliably. Repetition, use of pronouns, social conventions, all of these are used in our communications. One can use or tweak this to adjust the intent, causing double entendre, ambiguity, even humour. One can also apply contexts other than that of the source to derive a different meaning. Let me set up some context that will be used later.

Being a literalist, I take the phrase “all bears” to mean the totality of all objects such that each such object can be considered a bear, without qualifications. Thus, if not specified or otherwise modified, “all bears” refers to living and dead bears, mythical and teddy, polar and grizzly, bears that were, are, and shall be, and excludes many things, such as bookmarks or political statements. “Most bears” refers to a large subcollection of “all bears”, such subcollection usually being a majority. I use “many bears” and “some bears” to refer to a collection of bears which usually has 2 or more bears. “No bears” refers to an empty subcollection. I intend to avoid absolute statements, except in controlled circumstances.


The Joy of Beginning

I had the following pattern: I would get a diary, or a small planner, or some notebook with dates, and I would get it on or before New Years Day of the year that was stenciled on the outside of the diary/planner/notebook. I would write in it some notes that happened that January first of that year, and intend to write daily notes to journal some aspect of my life.

Many times this desire to journal tapered off within a few days, and I would be left with a journal of mostly blank pages. Sometimes it would take a whole week before I stopped my intense writing for the year. It might be the odd occasion when I would go back to that
to add some note or thought, but mostly I have a scattered collection of such small books which record my New Years resolve and its short-life.

There were a few times in my life when the resolve lasted for more than a month. One was when I decided to write various letters at the rate of one per day to parents, friends, acquaintances new and old. I still have that snapshot of that part of my life to substitute for a journal.

Another was when I decided to start this project. Elsewhere you will read of the events behind the inspiration for sdfae; one of them was writing material on a nightly basis for this endeavour, come what may. That year my resolve carried me for almost five months, up to and a little past the day when my mother died.

The enthusiasm for the project waned a bit, but it was always present. However, I stopped writing, and the material lay dormant for a few years. Even though I felt its importance, I shifted my focus to other matters, including moving my family.

There was a reason for the pattern, and I believe the reason was the joy of beginning. There is excitement, anticipation, some delight in the prospects of the future, and perhaps some nervous enjoyment of the unknown. One of the joys of system design is the joy of the beginning: each time you sit down to plan something new, the universe is yours to command, the potentials unlimited, the discoveries await, and the thrills yours to use as reward and motivation. I am excited at this beginning of sharing my thoughts on System Design For Almost Everyone. May you also experience the Joy of Beginning.

Copyright 2014 sdfae and Sheperd Systems

The Backstory

So I go to register, and find that Xinnet Technology Corporation beat me to it. Right now the domain is populated by information related to Shandong Financial Assets Exchange. Oh well. Also, I haven’t gotten some details to work on my Amazon instances, so the premiere date for the web services at and will be pushed back until further notice. Sorry for the change.

However, that is no reason for the crucial content to be delayed. Enjoy the Introductory Series of posts, and collect your comments and feedback into a text file. I hope to solicit mass feedback next week, about Oct. 7th. If you keep the feedback in a text file, you may be able to submit it to the website when it is up and running.

Enjoy! I look forward to conversing with you about System Design, and sundry other subjects.