ארכיטקטורה: האם לנסות שוב?!

לעתים אנו נתקלים בעת בניית המערכת בבעיות שקשה לפתור.

למשל: בעיות תזמון. אירוע אחד עובר לשני חלקי מערכת – מודול A ומודול B. מודול A עושה חישוב מתמטי קטן, ומגיב מהר, ומודול B קורא וכותב לבסיס נתונים ונעזר בשירות חיצוני. אנו רוצים שהתשובה של מודול B תגיע לאחר שיש במערכת תשובה של מודול A – מה שאכן קורה… ב 99.9% מהפעמים.

מה עושים ב 0.1% (עשירית אחוז) מהמקרים האחרים, כאשר דווקא מודול B מסיים ראשון?

סוג אחד של מתכנתים יישב לפתור לעומק את הבעיה. הבעיה מבוססת על מקרה אמיתי, אך תיארתי אותה בפשטנות יתרה. אפשר למצוא דרך לייצר lock / מנגנון סנכרון שיבטיח שבמקרים שמודול B מסיים ראשון – הוא ימתין למודול A שיסיים.

פתרון כזה ידרוש לעתים השקעה לא-קטנה – אך העניין יהיה מאחורינו.

סוג אחר של מתכנתים, יחפש פתרונות אג׳יליים ופשוטים למימוש. ״בוא נוסיף sleep של 500ms למודול ב׳ – וכך הוא תמיד יסיים אחרי״. הפתרון אמנם פשוט מאוד למימוש אך הוא נדחה על הסף על ידי הצוות: להאריך את התהליך כולו סתם בחצי שניה, עבור 99.9% מהמקרים  – זה לא נשמע סביר…
ננסה שוב: ״בואו נזהה מצב שמודול ב׳ מסיים ראשון, ואם זה קרה – נפעיל את כל התהליך בשנית״.

הפתרון הזה כבר זוכה להתעניינות משמעותית: לאתחל את התהליך מחדש – זו השקעה קטנה בקוד. במקרה מדובר בתהליך שניתן לבצע פעמיים, ללא נזק. הסיכוי לכשלון כפול הוא מאוד קטן: 0.0001% – אחד למליון. הפתרון הזה ייקח אולי שעה למימוש, בעוד ש lock בין שני המודולים – יכול לקחת יום – יומיים.

מה אתם אומרים?

אני באופן אישי מעדיף כמעט אוטומטית את הפתרון הראשון. נשקיע יותר – ונדע ״שהכל סגור״. לפתור את הבעיה ״אחת ולתמיד״. \"שונא סיכון\" – קוראים לזה.

כשאני מנסה לעשות realization לרצון הטבעי שלי אני מעלה גם ש:

  • תקלה של אחד למיליון היא עדיין תקלה. למה לתכנן משהו כך שיישבר (אפילו שהמקריות היא אחת-למיליון)??
  • הפעלת אותו התהליך פעם שנייה אינו דבר צפוי. אדם נוסף שייכנס לקוד עשוי לפספס / לא להבין זאת. 
    • עובדה שאין בעיה להפעיל את התהליך פעמיים כיום. מי מבטיח שתנאי זה לא ישתנה בעתיד? וכאשר הוא ישתנה – מישהו יזכור שיש לנו טריגר שמפעיל את התהליך פעם נוספת ויידע / יזכור לתקן את המנגנון?
  • אמנם תקלה למיליון לא נשמעת חמורה, אבל מי מבטיח לנו שתחת עומס / לחץ, המערכת שלנו לא מתנהגת אחרת? אולי תחת עומס מסוים – התופעה תתרחש אחת למאה פעמים?!
מצד שני יש כמה טיעוני-נגד:
  • המערכת שלנו עוד טרייה ותעבור שינויים רבים. להשקיע עכשיו יומיים בפתרון מקרה קצה – זו השקעה לא מידתית.
  • תקלה של אחד למיליון זה סיכון שניתן לקחת. בואו נהיה דוגריים: במערכת כנראה קיימים (ובעתיד יווצרו וייפתרו עוד ועוד) באגים אחרים שיגרמו להרבה יותר מ\"תהליך אחד למיליון\" להיכשל. עשינו Framing לדיון כאילו כל המערכת מושלמת – וזו הבעיה האחרונה שנותרה בה. זה לא המצב.
  • אחד למיליון נראה בעייתי? בואו נעשה ניסיון שלישי – אם צריך. בואו נזרוק Alerts למוניטורינג כאשר זה קורה – ונלמד אם באמת יש בעיה.
באיזה גישה אתה הייתם בוחרים?

באופן טבעי בארגונים גדולים וותיקים (מהניסיון שלי: SAP) הנטייה המקובלת היא בצורה מאוד ברורה לגישה הראשונה. בהקצנה: שם ווידאנו שהמערכות תומכת בעשרות שפות ובמשתמשים עיוורים – בכדי לצאת רק לבטא!

התבונה המקובלת היא: \"בואו נעשה את זה פעם אחת ולתמיד\".

באופן טבעי בארגונים קטנים וצעירים (אימפרבה, Gett – לא מאוד קטנים / צעירים) הנטייה המקובלת היא לגישה השנייה.
בהקצנה: ראיתי פעם ניסיון להוסיף שימוש חדש לטבלה קיימת (עם משפטי if שונים בקוד) – בכדי להימנע מיצירת טבלה חדשה.

התבונה המקובלת היא: \"בואו לא נסבך את זה\".

אלתור. יעיל, או חפלפ?  מקור: redstateeclectic

פתרונות שבבסיסם החשיבה היא \"אם יש תקלה – בואו ננסה שוב\", באופן אוטומטי מרתיעים אותי. במיוחד כאשר הם מגיעים מאנשים \"מעשיים\" שלא אוהבים להאריך בדיונים – ואז יש לי נטייה לסווג את הסיטואציה בראש אוטומטית כביטוי לחוסר מקצועיות.

במשך שנים בקריירה, הצעות מסוג זה נתפסו על ידי כחוסר מקצועיות, הבנה, או סבלנות נדרשת. כסמל של התנהגות שיש להוקיע. עבדתי אז ב SAP וקיבלתי גיבוי מלא לגישה הזו מעמיתי והמנהלים. פעמים רבות עבדנו עוד שבוע או שבועיים – בכדי לא להגיע לפתרונות של \"ניסוי שני\". לעתים, כאשר היה מדובר בשבועות רבים – היינו \"מתגמשים\" (ורושמים עוד שורה באקסל ה Technical Debt [א] שאז ניהלתי).

לכמה שורות באקסל הזה הגענו ותיקנו מאוחר יותר? בודדות. רוב הפרויקטים נסגרו / איבדו פוקוס – לפני שהספקנו לטפל בדברים. כלומר: לא טיפלנו, ולא סבלנו מכך במיוחד.
כנראה שלא היינו יעילים, כי בחרנו בגישה הראשונה בצורה אוטומטית וללא נכונות אמיתית לשקול את ה tradeoffs. אני זוכר שהשתעשתי ברעיון שלא רק הפתרונות הם סוג של Retries, גם אופן ההצעה שלהם הוא לעתים סוג של Retry: מישהו מציע פתרון, מקבל סירוב – ומהר מאוד מציע פתרון אחר… אולי הוא יצליח, וחוזר חלילה. הוקעתי אותם מהיסוד.

הבהרה: לא כל פתרון שיש בו אלמנט של \"Retry\" הוא בהכרח סוג הפתרונות שאני מדבר עליהם בפוסט. יהיה אולי נכון יותר לסווג את סוג הפתרונות בהם עוסק הפוסט כפתרונות \"מהירים ואופטימיים\" (למשל: כמו הוספת ה sleep, קביעת ערכי ברירת-מחדל שיגרמו ל flow להמשיך ולעבוד, וכו\'). אפשר לקרוא את הסיפור כיצד ייצבנו את המערכת שלנו בעזרת הכנסת retries לקריאות בין מיקרו-שירותים בפוסט הזה. זה לא היה בדיוק סוג ה Retry שאני מדבר עליו, כי זה לא \"ניסיון מהיר ואופטימי\". זה היה ניסיון \"יסודי, מבוסס ומנומק – אך אופטימי\" – משהו באמצע. הוא היה מגובה בנתונים ובחשיבה יסודית, אך אכן לא היה לנו שום בטחון שנשיג תוצאות בעקבות השינוי.

דיסקליימר נוסף: כארכיטקט הרבה יותר קל לבקר מהצד \"פתרונות מהירים\" שנעשים ע\"י אחרים. לארכיטקט יש פחות מחויבות ל Deliveries מהירים, משאר האנשים בפיתוח – שם הלחץ הוא מתמיד. אני מודה שכאשר היו פיצ\'רים שאני הייתי מעורב בהם והבטחתי למישהו שיקבל אותם בזמן מסוים – הייתי בהחלט הרבה יותר גמיש ל\"פתרונות מהירים ואופטימיים\".

לא ספר אמיתי 🙂

אז מה אני חושב על פתרונות \"מהירים ואופטימיים\"?

האם הם תוצאה של לחץ ואיבוד משמעת? (במידה – כן), או גישת עבודה יעילה ולעתים עדיפה? (לפעמים גם זה נכון).
בניגוד לנושאים רבים בהם יש לי דעה דיי ברורה על הנושא… בעניין זה באמת יותר קשה לי לספק עצות חד-משמעיות.

אני חושב שיש פה Tradeoff בסיסי, שנעשה לרוב בתנאים של חוסר-ודאות. קשה מאוד להעריך את התמורה לכל השקעה, ואפילו קשה לפעמים בדיוק להעריך מה ההשקעה שתידרש בפועל – במיוחד כאשר עוסקים בטיפול במקרי-קצה (aka \"איזור הדמדומים\").

\"לפתור את הבעיה אחת ולתמיד\" זו בעצם הגישה שאומרת להשקיע יותר בפתרון, ו\"בוא לא נתעכב\" זו בעצם הגישה שאומרת (you ain\'t gonna need it (YAGNI – להשקיע פחות.

אני חושב שצעד ראשון בכיוון ההתמודדות עם הדילמה הוא להסיר מעלינו את ה\"שייכות התרבותית\" שלנו בנושא:
זה לא עניין של \"נכון ולא נכון\", \"ארכיטקטים מול מפתחים\", או עניין של \"מקצוענות מול חפיפניקיות\". זה עניין של ניהול סיכונים והקצאת משאבים: כל קיצונות עשויה להיות הרסנית. אני חותם לכם על זה.

צעד שני הוא לשאול את השאלות הבאות:

  • עד כמה חלק הקוד המדובר הוא קריטי להצלחת הביזנס? עד כמה הוא מורכב ואנו סובלים מתחזוקתו? – ככל שהוא יותר מורכב ורגיש, נכון להשקיע יותר משאבים ולצמצם סיכונים.
    • מצד שני: ככל שמדובר באיזור קריטי למערכת – סביר יותר להניח שנחזור ונתקן / נשפר את ה \"Retry\" אם הוא לא מספיק טוב.
  • עד כמה המערכת צעירה / בוגרת? ככל שהמערכת בוגרת – יש טעם להשקיע יותר בכדי לשמר את האיכות והיציבות שהיא כבר השיגה. במערכת ממש חדשה – תקלה אקראית עשויה להיבלע בזרם בעיות גדולות וחמורות יותר. בעיות גדולות יותר יכולות להיות באגים, אך לא פחות מכך הן יכולות להיות פיצ\'רים חשובים שחסרים ללקוחות, או אי-התאמה בסיסית לצרכים העסקיים.
  • עד כמה ההתנהגות שאנו יוצרים היא צפויה? (Principle of least astonishment) – ככל שהפתרון ה\"אופטימי\" שלנו הוא מפתיע ולא-צפוי (יחסית להתנהגות הסדירה והמקובלת של המערכת) – כך גדלה הסבירות שהוא יישבר עם הזמן, או יגרום לבעיות שיהיה קשה לצפות. 
  • עד כמה קל לדעת אם ה Retry עובד? אם יש לנו שטף של אירועים מבוקרים ומנוטרים – קל יותר להצדיק התנסות ב\"פתרון מהיר ואופטימי\". סיכוני אבטחה (אירועים נדירים יחסית, אך אולי עם השפעה חמורה), למשל – הם מקום פחות מומלץ לעשות בו ניסויים.
    • הוספת Alerts למצבים בלתי צפויים סביב הפתרון – עשוי להיות מעשה נבון.
  • אל תנהגו בטיפשות. אל תעשו Retry על פעולות שאינן idempotent – כלומר פעולות שהפעלה שלהן מספר פעמים תסתיים בתוצאה שונה מהפעלה בודדת (למשל: חיוב של כרטיס אשראי).
בקיצור: It depends.
שיהיה בהצלחה!

[א] מונח המתאר את ה\"חובות הטכנולוגיים במוצר\". כמו חובות פיננסיים, נבון לעתים לקחת אותם – אבל אם הם תופחים הריבית היא בלתי-נשלטת ועלולה להוביל לאסון.
במילה Debt, אגב, לא מבטאים את ה b. זה נשמע כמו \"Technical Det\".

המתכנת הרציונלי

״מה שמייחד איש מקצוע אמיתי הוא ההתבססות על ידיעות – לא על ניחושים״. האם אתם מסכימים עם האמירה הזו?

משחר הימים, ה\"חשיבה העובדתית\" הייתה חלק זניח מסך החשיבה שהופעלה בקרב האנושות. הגיון (סובייקטיבי-אישי) ומיסטיקה היו המכוונים העיקריים לחשיבה ולהסקת-מסקנות: \"העולם מורכב מ-4 יסודות. זה ברור. אש ואדמה הם more of the same\". \"שטיפת הברכיים במים קרים וריצה על דשא רטוב היא מתכון בטוח לריפוי משפעת\"\', וכו\'.

בשלב מסוים (נאמר המאה ה-17) החלה החשיבה העובדתית להתבסס בקרב הקהיליה המדעית. סטנדרטים חדשים של ביצוע ניסויים מבוקרים, הסתמכות על הוכחות וביקורת על העובדות הידועות – החלו להופיע ולתפוס מקום חשוב בקרב הפעילות המדעית. שבריר זה של האוכלוסיה האנושית שהשתמש בחשיבה עובדתית (לא כולם, לא תמיד) הצליח לגרום לקפיצת-מדרגה בהשגי האנושות שלא נראו כמותה מאות שנים קודם לכן – מה שקרוי בפינו כיום \"המהפכה המדעית\".

לא סביר שכל האנושות, בכל רגע, תפעיל חשיבה עובדתית. …זה לא אנושי, כנראה.

אך אם עוד אחוז קטן מהאוכלוסייה יקפיד להשתמש ב\"חשיבה עובדתית\" עבור נושאים בעלי חשיבות – תיתכן התקדמות נוספת של האנושות. בעוד בקרב המדענים חשיבה זו דיי נפוצה, בקרב המהנדסים (אני יכול להעיד על מהנדסי תוכנה) – יש עוד מקום לשיפור. זה בדיוק מה שאיש מקצוע רציני היה רוצה לעשות.

הטיות אנושיות

מי שקצת עקב אחרי עבודתם של טברסקי וכהנמן או הספרים של דן אריאלי (פסיכולוגים של הכלכלה) – מודע היטב להיבטים רבים של ההתנהגות האנושית המודרנית ש״איננה רציונלית״. המוח שלנו משתמש ביוריסטיקות, \"קיצורי דרך\", על מנת להגיע להחלטות. קיצורי הדרך לעתים עובדות יפה – ולעתים לא.

לדוגמה: אחת היוריסטיקות החזקות ביותר הידועות היא יוריסטיקת העגינה. ערך מספרי ראשון שאנו שומעים – יעגן אותנו לאותו אזור ערכים ולא נוכל להשתחרר ממנו, לא משנה אם הוא הגיוני או לא. חוקרים הצליחו להטות בצורה משמעותית הערכה מקצועית של שמאים לגבי ערך בתים רק ע\"י כך ש\"זרקו\" מחיר במהלך הביקור – גבוה או נמוך.
יתרה מכך – הסתבר שגם מספר מגוחך לחלוטין שאינו קשור למציאות עדיין משפיע עלינו. \"2.1 טריליון פאונד\" יכול החוקר לזרוק לשמאי שבא לסקור דירת חדר בלוד – ולהשפיע על השמאי בעשרות אחוזים.
לא רק שמאים חשופים להטיה – כל בני האדם חשופים.
ההטייה של יוריסטיקת העגינה פועלת גם כאשר מזהירים את האנשים מראש ומסבירים להם כיצד מתכוננים להשפיע עליהם.
ההטיה פועלת גם בהקשרים-לא-קשורים: סטודנטים נתבקשו להעריך מידות מספריות, מיד לאחר שהם נשאלים מה הספרה האחרונה במספר ת\"ז שלהם. אלו שהספרה שלהם היתה גבוהה (7,8,9) נתנו הערכות גבוהות באופן מובהק מאלו בעלי ספרה נמוכה (1,2,3).

הטיות אנושיות מוכרות מוכרות אחרות כוללות \"מציאת תבנית\" (pattern) לא קיימת בנתונים אקראיים – וייחוס חשיבות לקשר[א], השפעה מתכונה אנושית אחת (למשל: יופי חיצוני) על הערכת תכונה אחרת לא קשורה (למשל: טוב לב, חכמה) – מה שנקרא אפקט ההילה, ועוד.

התמונה הזו גרמה ללא-מעט אנשים להסיק שהשטן בעצמו הוא האחראי לפיגועי ה 9/11 ולא סדאם חוסיין, כלומר… היהודים או ה CIA.
מרגע שזיהינו תבנית – אנו ממהרים למצוא לה משמעות ולהתמיד באמונה בה. האם אנו יכולים להיות טובים מזה?

העגל רוצה לינוק
כבני אדם, אנו בנויים על מנת לינוק מידע. יש לנו נטייה ברורה להעדיף דברים שאנו רוצים לשמוע על פני דברים שלא.
כשאנחנו מחפשים אחר מידע, אנו מחפשים בצורה מגמתית שסביר יותר שתוביל אותנו להיכן שאנו רוצים להגיע. מצאתי את עצמי, לא פעם, מבצע בגוגל שאילתות כגון \"SomeTechnology> good performance>\" או \"\'why use TechA\". כמובן, שמצאתי תוצאות שהשביעו את רצוני והמשכתי עמן הלאה: מצגת, שכנוע, החלטה.

כשעשיתי את התרגיל וחיפשתי את השאילתות ההפוכות: \"SomeTechnology> poor performance>\" או \"techA problems\" – מצאתי, לעתים קרובות, תוצאות מספקות שהיו יכולות לשרת אותי אם הייתי רוצה לטעון את ההפיך הגמור.
כנראה שהיה לי נוח להתעלם מכך שהתוצאה שמצאתי היא דעה, לעתים דיי בודדה. מספיק היה לי למצוא 2-3 כאלו בכלל בגוגל – על מנת לקבל את הטענה של הדעה כעובדה.
היו מספר סימני אזהרה שיכולתי לשים לב אליהם – אבל לרוב בחרתי להתעלם. את סימני האזהרה הללו ניתן ללמוד.
עם השנים אני מנסה להשתפר וברגע שאני עושה חיפוש אני מחפש וקורא ברצינות גם את אלו שאומרים את ההיפך. לא תמיד. לפחות כשמדובר בעניינים חשובים ולא בזוטות.

\"חיפוש ההופכי\" היא כמובן רק דוגמה אחת לטכניקה שיכולה לסייע לנו לעבוד ע\"פ אמות מידה של \"חשיבה עובדתית\". ישנם כמובן עוד הרבה שניתן לעשות.

כששומעים משהו נפלא, ניתן לרגע להניח שאכן כך, ולחשוב מה ההשפעות הצפויות מכך. האם הנתונים בפועל מצביעים על משהו דומה?
לדוגמה: שמעתי בארוחה עם חברים על רכב מונע אוויר-דחוס הנוסע 200 ק\"מ בעלות של 1$. אין לי שום מושג בנושא – אך לאחר שנים והשקעה רבה כ\"כ ברכבים היברידיים / חשמליים (שלא לומר: פרפטומובילה) – קשה להאמין שהישג רציני ומבוסס כזה הושג מבלי שיציף את כל ערוצי החדשות.

מאמץ להשתמש ב\"שפה גבוהה ומתוחכמת\" או להיצמד לשמות גדולים (גוגל, אפל, וכו\') – יכולים גם הם להיות סימני אזהרה ברורים למידע לא רציני[ב].

הטיית השטן

הסיבה שבגינה יש להיזהר ולבדוק את עצמנו כפליים היא שעל כוכב הלכת ״ארץ״ יש תעשייה שלמה, מכניסה למדי, של ברנשים שכל תפקידם הוא להטות את דעותינו לכיוון זה או אחר. זוהי עבודתם של אנשי שיווק, פרסום ומכירות (לא תמיד הגדרת התפקיד שלהם נשמעת כמו \"שיווק\" או \"מכירות\") – ויש להם אינטרס ולחצים אמיתיים להשפיע על אנשים אחרים ועל החלטותיהם. לעתים קרובות, יש להם משאבים רבים (הוצאות של 50% מכלל התקציב של הארגון על שיווק/מכירות הוא לא מחזה נדיר), ידע מדעי וכלים מעשיים יעילים על מנת לעשות זאת. כלומר: הטעויות בעובדות שאנו עשויים להיתקל בהן, הן לא אקראיות – כי אם מכוונות.
אפשר להקביל זאת להבדל בין בטיחות לאבטחה: בטיחות מגנה עלינו מכשל אקראי, בעוד אבטחה צריכה להתמודד עם אויב תבוני שיחקור ויחפש את הנקודה החלשה ביותר להכות בה. כך גם בקבלת החלטות שבה יש למישהו שמץ של רווח או עניין  – יהיה מישהו שינסה להציג או להבליט נתונים בצורה מגמתית. סביר שאותו אדם ישתמש בהטיות פסיכולוגיות ידועות בכדי להגביר את השפעת דבריו. כנראה שיש לו יותר ידע ואמצעים מאשר \"מטרות ההטיה\". אני מבין שהצהרה זו נשמעת קצת מבהילה, אך זכרו: זה שאתם פרנואידים לא אומר שלא רודפים אחריכם, וקצת יותר ברצינות: במהלך עבודתנו אנו משתמשים בנתונים רבים שיש לאחרים אינטרסים רבים לגביהם. הסיכוי שלכם להיתקל בנתונים שהוטו הוא גדול למדי. לא כל שימוש בנתון מוטה מוביל להחלטה לא-טובה: לעתים קרובות זמינות הנתונים הם אלו שמאפשרים את עצם ההחלטה, אך כדאי להיות מודעים למשחק שמשוחק פה. מרצים בכנסים, ספרים, בלוגים מאמרים במגזינים ודוח״ות אנליסטים, כולם כפופים לניסיונות להטיית הדעה וקידום האג׳נדה. לא מדובר במקרים בודדים – כי אם בשגרה.
הצהרה: בבלוג זה, עד היום, לא הייתה שום הטיה מכוונות או ניסיון לשכנע במשהו שאנני מאמין בו בלב שלם. אם הייתי מקבל ממישהו הצעה אטרקטיבית להבליט משהו (טכנולוגיה, מוצר וכו\'), \"בצורה לא פוגענית ושתשרת בעיקר את האינטרסים של הקוראים\"[ג] – כנראה שהייתי שוקל.

מילת סיכום

השימוש בהטיות אינו מעיד על אי-נכונות או אי-רצינות הטיעון. לעתים אנשים משתמשים בהן על מנת להעצים את המסר (יש לפחות 2 הטיות מודעות בפוסט זה) ולעתים רבות ההטיות הן לא-מודעות ו\"מתגנבות\" לטיעון. אנו בני-אדם ולא סביר שנוכל להימנע מהן לגמרי.
חלק חשוב מחשיבה ביקורתית בריאה, כפי שציין בפני ערן, היא להכיר בסבירות שלנו לטעות ולהיות פתוחים באמת לקבלת ביקורת ותיקונים ענייניים. זה לא תמיד קל ולא פשוט, לשים את האגו בצד ולקבל תיקון במיוחד אם מדובר במישהו שלא \"ציפינו\" שיציע תיקון, למשל מישהו פחות מנוסה מאיתנו. מצד שני, היכולת לקבל תיקון תקדם אותנו הלאה לשלב מתקדם יותר של \"חשיבה עובדתית\".

שיהיה לנו בהצלחה!

תודה לאביב, ליאורה, ברק, ירון ובעיקר ערן, החבר\'ה של \"ספק סביר\" – פודקאסט ספקני-מדעי (מומלץ!), שנכונו לסייע ולייעץ לגבי פוסט זה.

[א] תרגיל מעניין הוא השמעת קטעים מוזיקליים לאחור – מה שהופך אותם לרצף דיי אקראי, ומציאת \"מסרים סמויים\" ברצף. ב http://jeffmilner.com/backmasking/ תוכלו למצוא כמה דוגמאות. לא סביר שתוכלו להבין משהו מהקטעים שמושמעים לאחור, אך לאחר שתקראו טקסט ההסבר (לדוגמה: \"James Brown is dead\") – יהיה קשה לכם להתכחש לכך שזה בדיוק מה שנאמר שם. לאחר שהורגלו ברעיון (\"זיהינו את התבנית\") – קשה לנו לחזור בנו ולהתעלם ממנה.
[ב] ברוס וויליס ואפל – הם כבר 2 שמות גדולים שמספיקים לסיפור טוב, חסר ביסוס. הנה מכתב שרשרת (בדוי) ששורד כבר 7 שנים ברשת ועדיין נשלח. איך? יש בו כמה שמות גדולים שגורמים לנו כאנשים לנטות ולהאמין…

[ג] כרגע הרעיון לא כ\"כ נראה לי + אני נמצא ב mindset הפוך, ולכן אינני מצליח להיות משכנע במיוחד. אני מאמין שעם סיבה מספיק טובה, ועזרה מבחור חלקלק – הייתי מצליח לשכנע את עצמי ואחרים \"שזה גם לטובת הכלל\". בעצם – רק לטובת הכלל. אלטרואיזם.