Principles 28-29

"Even small changes introduced to the system may produce discontinuous, unpredicted effects (28).

Adaptive changes within a system can grow from learning generated by the individual interactions in the networks of system participants (29)."

(Metropolitan Development as a Complex System:  A New Approach to Sustainability, Judith E. Innes and
David E. Booher, Working Paper #699, University of California at Berkeley, December 1997).

Thoughts about Thinking-Intentions Profile (TIP)

Last Saturday I was introduced to Thinking-Intentions Profile, a powerful coaching technique. The process is conducted in a group of 3-5 people and is divided into five stages:

1. The coached person clearly states his or her problem statement or some other issue.

2. Group coaches start asking direct questions.

3. The coached person steps out from the the discussion and the coaches discuss impressions as if the coached person is not in the room.

4. The coached person is re-invited into the discussion and is offered a list of solutions

5. The coached person is given an opportunity to select appropriate recommendation and commit to them.

Prime deliverable of the coaching session: validation or invalidation of the problem statement. If the coached person is able to validate or invalidate of her/his problem statement by the end of the coaching session, then the minimal goal of the session was achieved.  In other word, it is important for the coached person to verify her/his perception in the actual context. By context I mean the social environment of the given individuals. Collective coaching represents a micro-model of such environment.

Thrust and objectivity of the coaches. Trust established between the coaches and the couched person helps the questions to be asked and answered as clear as possible. In other words, distrust between two parties creates distraction for the cognitive process. Such process should not tolerate any elusive statements and unspecified assumptions. Limited experience with this method does not allow me to say if the coached person should be taken out from his/her comfort zone. Perhaps such techniques can be useful when the group reaches a preliminary conclusion that the initial problem statement is invalid.

Discussion requires self-discipline form the coaches and tolerance from the coached person. The “out of the room”/ “behind back” simulation opens door for initial discussion. However, the substance of the discussion has to be sustained within or near acceptable border of the coached person. Otherwise, sharp criticism or insensitive comments may easily turn defensive mechanisms of the coached person ruining the purpose of the session.  It is important that the coaches are able to skillfully balance on the border of acceptable and unacceptable criticism/comment/etc.  Defining such borders by trail and error (forward and backward, expansion vs. contraction) is key in shaping physiological portrait of the coached person.

Solutions. This stage allows infinite number of possibilities and solutions. The level and degree of the relationship between the coaches and the coached person dictates the dynamics of this stage.  Difference or similarities in age, gender, race, religion, language, culture, etc will define acceptable limits of this stage.

Commitment can be the most sensitive stage of the coaching. It is only a temporary or formal closure of the process.  Once the process of coaching is started, it has a life of its own. Afterthoughts and reevaluations may take numerous iterations, time, effort and emotional energy.  It is an important detail that some amateur coaches are not ready for.  It is the biggest warning that should keep away such amateur coaches from taking this responsibility from the beginning. Another important detail is that the coached person may or may not commit to the suggested solutions. Depending on the situation, the coached person may not openly commit to some suggestions and tacitly reject other suggestions.

Lessons learned. I call it an emotional cycle. Thrust creates clarity. Trust also builds connection/bond. Clarity helps to identify problem and give suggestions. Commitment to some of the suggestions reinforces the bond. The bond cannot be broken if you want to maintain the thrust. The art of coaching is an ability to understand this dynamic and stay outside of it at the same time.  It is similar to the skills of the successful doctor, who is able to remain empathetic and professional at the same time.

Principle 27

"Do not plan a testing effort under the tacit assumption that no errors will be found" (Nancy Leveson, ESD.355)

Brain-storming on my thesis "Founder-CEO succession"

Well I have one more year to go but I started to think about what topic should choose for my thesis. If we assume that Founder-CEO is a designer and an operator of a company. Company is a system.  Founder-CEO knows how the system operates and how it behaves.  Successor is a less experienced operator with only formal knowledge of the design of the system. What is the operator-system interface? How can we customize such interface for new operator? How will new operator learn about “behavior” of the system? What are key symptoms for system’s failures?

For now there are three initial and very raw thoughts.

Topic  A: Roadmap for Founder-CEO succession: key symptoms and characteristics

(1) Successful transition

(2) Failed transition

Topic B: Metal models for Founder-CEO succession:

As in Good to Great (?) from level 1 to level 5 (?)

Topic C: Rule-based system as a model for Founder-CEO succession

Thoughts on STAMP (Systems-Theoretic Accident Model and Processes)

New Accident Model for Engineering Safer Systems (Leveson, http://sunnyday.mit.edu/16.355/)

Symptom – “something that indicates the existence of something else”, Webster dictionary http://www.merriam-webster.com/dictionary/Symptom



It is my understanding that STAMP focuses on “constraints necessary to limit system behavior to safe changes and adaptations” (p.12). The model briefly touches upon a symptom as “the process leading to an accident (loss event)... described in terms of an adaptive feedback function that fails to maintain safety as performance changes over time to meet a complex set of goals and values” (p.26).

Reading this article I kept asking myself if complex systems are just “complex and often imperfect human artifact”, could one characterize symptoms of upcoming accidents? In other words, if we can classify accident factors (p.21), can we characterize accident symptoms?

The article briefly mentions that “proximity” to systems has changed over time (p. 14). In the past, operators had direct access to their systems and were able to get “direct physical feedback” from the system. More experienced operators could have indentified changes in the system’s behavior or “feel” erroneous symptoms (or what is called “detect maladaptive changes” p.26).  Such ability usually came from “gut feeling” or intuition, which in reality was based on previous experience and undocumented assumptions.

Modern complex systems do not give us luxury of “feeling” the system. Moreover, post-mortem accident investigation may not reveal the symptoms that operators failed to recognize before that accident. Available factual data may not necessarily lead us to the correct interpretation of that data (p.26). But we may assume that such symptoms are usually non-linear, dynamics (with feedback loops) and adaptive to the environment.

It might sound as gross generalization, but I argue that STAMP should not only help to control the “beast”, but also explain “why and when the beast wants to get out from the cage”.  I will take a risk of classifying such symptoms into three categories:

(1) external symptoms: symptoms that emerge as the result of external socio-technical environment (including change and adaptation of new safety constrains) that forces the system to adapt and lead to maladaptive changes. This can be categorized as expected and inevitable results if and when erroneous processes influence the system and its environment.

(2) interface symptoms: symptoms that emerge as the result of interaction between the system and its operator, the system and other systems. This is the closest we can get to the old way “feeling the vibration” the system and being able to get feedback from it.

(3) internal behavioral symptoms: unintended or unforeseen symptoms that can be best identified by the designer or peer-reviewers of the system. My intuition, tells me that this is the most difficult symptom to indentify and categorize (and decompose), which can be done only through extensive testing of the system.

Social Processes and Proofs of Theorem and Programs (Lipton, Perlis, DeMillo)

I have to admit that I included this article into my top ten list of articles read at MIT this semester.

“If mathematical process were really one of strict, logical progression, we would still be counting on our fingers.”

The article opened me a small window into the world of mathematicians. Our distorted understanding of the their world lead us to erroneous perception of how software programming “world” operate.  In both of these worlds, social processes, which are not necessarily obvious to an outsider, are major driver in test and acceptance of new ideas, theorems, products and systems.

The authors argue that "A program is a human artifact, a real-life program is a complex human artifact; and any human artifact of sufficient size and complexity is imperfect.” Thus people are not able to “create perfect mechanisms and   verification process is nothing but a model of believability”.  As the result, software programs have to be reliable but not necessarily perfect.

A conclusion that can be drawn from the article is that in software engineering social processes have to more visible and acceptable form of test and acceptance. By social processes I mean per-reviews, beta-user reviews and end-user reviews. These processes may not completely verify the system, but encounter the system with the real-world environment and force the designers of the system to adopt it.

Bill Warner lecture on Intentions and Inventions (ESD.34, MIT, November 6, 2009

"Transform space 1: I intend to help people tell THEIR story. This is a timeless intention. Transform into timeless human space. Intentions are main drivers. People have multiple and certain intentions. There is one primary timeless intention. This intention is making people tell their stories.

Intention domain (language of intention) - ideas, simple language, make yourself slowdown (this will transform you into different space). Making energy going out from you: "the light that comes out".

Invention domain - what you can see or make. The intent is encoded in the invention. It is not visible, only the person who invented a system can tell the initial intent. The trick of reverse engineering - look how you FEEL when you used the product. You will get closer, but still have fragment picture of the intent.

Beliefs domain - system design requires philosophy all the time. The belief domain is something that connects or blocks intentions from inventions.

Transform space 2: I intend to help people follow their heart.

As long as you have timelessness, it is timeless intention. Everything that is time relevant has to do with invention. It is very easy to invent from primary intention, because you do it for the people who have needs, you really care to commit and solve this problem. It is not driven by your EGO. Almost all the time "your people" are not the one who pay for the product (indirect flow).

Google Inc. is the biggest "INTENTION FLOW" machine ever created in the human history.

Transform space 3: I intend to feel closer together.

You are an architect and you are an architecture.

Your product goal is to help other people.

Your product form is human body, but run on Human Nature 1.0 (a constant over time).

Beliefs are changing over time.

Intention flowing = helping

We OVER-INVENT and UNDER-INTENT.

Intent gives wide range for inventions."

Principle 26

"1. Capabilities, Not Just Strategy.

2. Pull, Don't Just Push.

3. Scope, Not Just Scale.

4. Flexibility, Not Just Efficiency.

5. Platforms, Not Just Products.

6. Services, Not Just Products (or Platforms)"

(Michael Cusumano, lecture "In Search of Best Practice: Enduring Ideas in Strategy, Innovation and Technology Management" on the 24th Forum on COCOMO and System/Software Cost Modeling), November 5, 2009.

Principle 25

"A program is a human artifact, a real-life program is a complex human artifact; and any human artifact of sufficient size and complexity is imperfect" (De Millo, Lipton, Perlis. 1979.

Principle 24

“It is the last lesson of modern science, that the highest simplicity of structure is produced, not by few elements, but the highest complexity” (Ralph Waldo Emerson).

Principle 23

"An important distinction to be made between programs properties that cause the program to be complex and program characteristics that are associated with complexity" (Kearney, 1986).

Principle 22

"Complexity usually arises from a small number of disproportionally complex procedures" (Henry, Kafura, 1984).

Principle 21

"Solving a problem involves mapping into knowledge available" (Nancy Leveson, ESD 355 lecture).

Principle 20

... "an architecture of a specific system [is] a collection of computational components—or simply components-—together with a description of the interactions between these components—the connectors... An architectural style, then, defines a family of such systems in terms of a pattern of structural organization.  More specifically, an architectural style determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints  on how they can be combined... Given this framework, we can understand what a style is by answering the following questions:

(1) What is the structural pattern—the components, connectors, and constraints?

(2) What is the underlying computational model?

(3) What are the essential invariants of the style?

(4) What are some common examples of its use?

(5) What are the advantages and disadvantages of using that style?

(6) What are some of the common specializations?"

(David Garlan, Mary Shaw. An Introduction to Software Architecture, 1994)

Principle 19

"The conversion from an intuition to a theory involved understanding:

(1) the software structure (which included a representation packaged with its primitive operators),

(2) specifications (mathematically expressed as abstract models or algebraic axioms),

(3)  language issues (modules, scope, user-defined types),

(4) integrity of the result (invariants of data structures and protection from other manipulation),

(5) rules for combining types (declarations),

(6) information hiding (protection of properties not explicitly included in specifications)."

(David Garlan, Mary Shaw. An Introduction to Software Architecture, 1994)

Principle 18

"Simplification results in fundamentally wrong answers, and focus on individual sectors separately will be counterproductive"

(Metropolitan Development as a Complex System:  A New Approach to Sustainability, Judith E. Innes and
David E. Booher, Working Paper #699, University of California at Berkeley, December 1997).

Principles 15-17

"Dijkstra, Hoare, Wirth:

Construction of correct programs requires that programs be intellectually manageable (15).

Key to intellectual manageability is the structure of the program itself (16).

Disciplined use of a few program building blocks facilitates correctness arguments (17)."

Form Nancy Leveson, ESD 355

Principle 14

"To achieve an efficient implementation we must abandon the assumption that a module is one or more subroutines, and instead allow subroutines and programs to be assembled collections of code from various modules" (Parnas, 1971).

Principle 13

"Accidents result from interactions among components that violate the safety constrains - in other words,  from a lack of appropriate control actions to enforce the constrains of the  interactions"  (Nancy Leveson, A New Accident Model for Engineering Safer Systems).

Principle 12

"Effects cannot be directly linked to causes because an intervention reverberates through the system in ways that can only be partially traced"

(Metropolitan Development as a Complex System:  A New Approach to Sustainability, Judith E. Innes and
David E. Booher, Working Paper #699, University of
California at Berkeley, December 1997).

Principles 11

"As for aesthetic value, I would bet on the architect whose project reflects enduring human values in architecture" (Catesby Leigh, Guest lecture for ESD.34, 2009).

Principles 6-10

6. "If you cannot explain it in five minutes, either you do not understand it or it does not work." (Darcy McGinn 1992, David Jones).

7. "All the serious mistakes are made on the first day" (R.Spinrad,1988).

8. "If it cannot wait it will" (Murphy's Law).

9. Development Process is useful for the following reasons (Ulrich K.T., Eppinger S.D., Product Design and Development, McGraw-Hill Inc. New York, NY, 2007.):

- Quality assurance,

- Coordination,

- Planning,

- Management,

- Improvement.

10. The Five Phases of Generic Development process are (Ulrich K.T., Eppinger S.D., Product Design and Development, McGraw-Hill Inc. New York, NY, 2007.):

"...

- Concept Development - single concept is chosen from a list of alternatives. The concept is described in form, function and features, accompanied  by specifications.

- System Level Design - definition of the product architecture, division of the product into subsystems (and their functional specifications), creation of geometrical layout of the product.

- Detail Design - complete specification of the geometry, materials, and tolerances of all of the unique parts in the product. A process plan is established and control documentation is delivered.

- Testing and Refinement - construction and evaluation of multiple pre-production version of the product. Alpha and Betta prototypes.

- Production ramp-up - product is made using the intended production system..."

Principles 1-5

1. "There are no such things as good companies, bad companies or tired companies. There are good leaders, bad leaders and tired leaders" (Shalom Saada Saar, from ESD.930 lecture).

The four Heuristic from The Art of System Architecture (Rechtin E., Maier M.W., 2009):

2. Do not assume that the original statement of the problem is necessary the best, or even the right one.

3. In partitioning, choose the element so that they are as independent as possible; that is elements with low external complexity and high internal complexity.

4. Simplify, Simplify, Simplify.

5. Build in and maintain options as long as possible in the design and implementation of complex systems.

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!