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

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

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

הפתרון הנכון לא חייב להיות מסובך. כשמחזקים ארון עם יותר מדי ברגים זה לא הופך אותו לחזק יותר זה רק מסבך את הייצור ללא צורך אמיתי. הפתרון הנכון בתוכנה הוא הפתרון שדורש הכי מעט משאבים כדי לפתור את הבעיה שנמצאת אצלנו מול העיניים ומייצר הכי פחות משקל עודף - כלומר אילוצים שיסבכו אותנו במימוש פיצ'רים עתידיים.

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