Good Enough Engineering

אחרי תקלות, אחרי Incident response, ואחרי שראינו איך תרבות משפיעה על התנהגות בזמן אמת - עולה השאלה הקשה באמת:

מתי לעצור.

האשליה: “אם זה לא מושלם - זה מסוכן”

מהנדסים נמשכים לשלמות. קוד נקי. ארכיטקטורה אלגנטית. פתרון שמכסה כל קצה.

הכוונה טובה. הסיכון - גדול.

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

למה שלמות מסוכנת למערכות חיות

כל שיפור “קטן” מוסיף:

• מורכבות
• תלות
• ועוד הנחות שצריכות להחזיק

וככל שהפתרון “שלם” יותר:

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

מערכת מושלמת על הנייר עלולה להיות שבירה במציאות.

Good Enough אינו חוסר מקצועיות

Good Enough Engineering אינו ויתור. הוא בחירה מודעת.

זו ההבנה ש:

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

Good Enough שואל: מה מספיק כדי שהמערכת תחזיק - גם כשדברים משתבשים?

מתי לעצור

הנקודה לעצירה אינה טכנית בלבד. היא הקשרית.

עוצרים כש:

• התוספת הבאה משפרת אלגנטיות, לא יציבות
• הפתרון כבר קשה להסבר לצוות
• והעלות התפעולית עולה מהר מהתועלת

זה הרגע שבו “עוד קצת” מתחיל לעבוד נגדך.

פתרון עם שוליים, לא פתרון מושלם

מערכות יציבות מעדיפות: פתרון שיש לו מרחב תמרון על פני פתרון שאין לו לאן לזוז.

שוליים מאפשרים:

• טעויות בלי קריסה
• שינויים בלי פאניקה
• ותקלות בלי אובדן שליטה

שלמות, לעומת זאת, סוגרת אפשרויות.

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

הנדסה טובה אינה נמדדת בכמה הכול מכוסה.

היא נמדדת:

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

Good Enough Engineering אינה פשרה על איכות - היא פשרה עם המציאות.

מבט קדימה

אחרי שלמדנו:

• מתי לעצור
• ואיך לא לרדוף שלמות

נשארת שאלה אחת אחרונה:

מה קורה כשעוצרים מעט מדי - או יותר מדי?

בפוסט הבא נעסוק בשני הקצוות המסוכנים: Over-engineering ו-Under-engineering, ולמה שניהן נובעים מאותה טעות.