Over-engineering ו-Under-engineering: שני צדדים של אותה טעות

אחרי שדיברנו על Good Enough Engineering ועל היכולת לעצור בזמן, נשארת טעות אחת נפוצה במיוחד:

לעצור מוקדם מדי - או מאוחר מדי.

האשליה: “יש פתרון נכון אחד”

נהוג לחשוב ש:

• Over-engineering הוא חוסר ניסיון
• Under-engineering הוא רשלנות

אבל בפועל, שתיהן נולדות מאותה הנחה שגויה:

שיש פתרון “נכון אבסולוטית”, מנותק מהקשר.

Over-engineering: פחד שמתחפש למצוינות

Over-engineering לא נובע מעודף ידע - אלא מפחד.

פחד מ:

• תקלות עתידיות
• ביקורת
• או מהשאלה “למה לא חשבתם על זה?”

התוצאה: פתרון שמנסה לכסות הכול.

עוד שכבה. עוד abstraction. עוד תרחיש קצה.

אבל:

• קשה להבין אותו
• קשה לשנות אותו
• וקשה לעצור אותו בזמן תקלה

המערכת אולי “מרשימה” - אבל היא שבירה.

Under-engineering: ביטחון שווא שמתחפש לפשטות

Under-engineering אינו תמיד עצלות. לעיתים הוא ביטחון מופרז.

האמונה ש:

• “נסתדר כשנגיע לשם”
• “זה כנראה לא יקרה”
• “אם תהיה בעיה - נוסיף אחר כך”

התוצאה: פתרון שאין לו שוליים.

אין:

• מקום לטעויות
• מקום לעומס
• מקום לשינוי

וכשהמציאות חורגת קצת מהצפוי - המערכת נשברת מיד.

הטעות המשותפת

Over-engineering ו-Under-engineering נראות הפוכות, אבל שתיהן מתעלמות מאותו דבר:

מהקשר.

הן אינן שואלות:

• מי יתחזק את זה?
• איך זה יתנהג בפרודקשן?
• מה המחיר של שינוי?
• ואיפה באמת הסיכון?

בשתיהן, הפתרון נבנה מתוך הנחה - לא מתוך מציאות.

הנדסה בוגרת היא כיול, לא קיצון

הנדסה יציבה אינה:

• הכי פשוטה
• וגם לא הכי מתוחכמת

היא מכוילת.

היא שואלת:

• מה הסיכון הדומיננטי עכשיו?
• מה העלות של טעות?
• ואיפה עדיף להשאיר חוסר שלמות מכוון?

זו לא פשרה. זו שליטה בהקשר.

סימנים אזהרה מוקדמים

אפשר לזהות קיצון די מוקדם.

Over-engineering מרגיש כמו:

• פתרון שקשה להסביר
• קוד שאף אחד לא “נוגע בו”
• מערכת שאי אפשר לשנות בלי פחד

Under-engineering מרגיש כמו:

• מערכת שאין לה Plan B
• פתרון שעובד רק “בתנאים טובים”
• תלות בשגרה שלא באמת קיימת

שניהם מסוכנים - מסיבות שונות.

השורה התחתונה

הבעיה אינה אם פתרון “פשוט” או “מורכב”. הבעיה היא אם הוא מתאים למציאות שבה הוא חי.

Over-engineering ו-Under-engineering הן שתי דרכים לברוח מהשאלה האמיתית:

מה המערכת הזו באמת צריכה - עכשיו?

מבט לסיום הסדרה

אחרי שראינו:

• איך Production חושף אמת
• איך Latency, שינוי וארגון משתלבים
• ואיך יציבות הנדסית נראית בפועל

נשאר לסכם את הכול למשפט אחד ברור.

בפוסט הסיום נעסוק בזה:

למה מהנדסים אחראיים לא מחפשים שליטה במערכת - אלא יוצרים תנאים שבהם היא לא יוצאת משליטה.