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

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

ואפשרות שלישית והכי פחות כיפית היא להתעלם מהסיבוך או לשכנע את העולם שאין ברירה. יש פונקציה שמקבלת 15 פרמטרים? אין מה לעשות, היא עושה הרבה דברים. קשה לעבוד עם קוברניטס? אין מה לעשות מערכת הפעלה זה דבר מסובך. לאורך זמן גישה כזאת נוטה להפוך מערכות להרבה יותר מורכבות ממה שצריך, ואת המתכנתים להרבה פחות מאושרים ממה שאפשר. דוגמה עצובה במיוחד שנתקלתי בה היא Issue 9643 מספריית fluentui, שמסתיים במילים:

Due to the complexity and dependencies of our List components, we are not able to take new feature requests at this time.

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