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

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

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

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

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

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

3. אני יכול להעלות את הקוד למערכת כמו Heroku כדי להגיע לאוויר כמה שיותר מהר, ולדחות את כתיבת קוד ה Deployment המסובך לאחרי שהמוצר באוויר.

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

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