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

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

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

כשאנחנו מתלבטים איך לממש פיצ'ר מסוים חשוב לשים לב להתלבטויות ולשיקולים ולהבדיל בין שני הסוגים, כי כל סוג מייצר שיחה אחרת:

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

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

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