מאיפה להתחיל
בתיאוריה כשבאים לבנות פיצ'ר זה בכלל לא חשוב ממה מתחילים. בפרקטיקה זאת יכולה להיות השאלה שתקבע את גורל הפיצ'ר.
יהיו מתכנתים שיבחרו להתחיל מה UI ויבנו קודם את ה HTML/CSS (או יקנו תבנית מתאימה)
יהיו את אלה שיעדיפו להתחיל מבסיס הנתונים וקודם כל יגדירו את הטבלאות וקוד צד השרת.
יהיו מתכנתים שיבחרו להתחיל מכתיבת בדיקות אוטומטיות. כן, הבדיקות ייכשלו אבל לפחות יהיה לנו כיוון למה צריך לממש כדי שהן יעברו בסוף.
ויהיו את אלה שיחפשו קודם האם יש ספריה קיימת שפותרת את הבעיה בלי שיצטרכו לכתוב שורת קוד אחת.
וכל עוד אתם בתוך ה Comfort Zone שלכם אז הבחירה מאיפה להתחיל את הפיצ'ר הבא נראית שקופה, כמעט אוטומטית. ככה אנחנו עובדים פה. אבל אז מגיע רגע שיוצאים מאזור הנוחות, ופתאום צריך לבנות משהו שלא חשבת עליו קודם: פיצ'ר שאין לו קוד צד-שרת; או פיצ'ר חדש שהוא כולו בבסיס הנתונים או בכלל רץ ב Serverless.
הסכנות בבחירת נקודת התחלה לא נכונה היא הערכה לא נכונה של עלות המשך הפיתוח, בזבוז זמן על דברים לא חשובים ובסוף גם אובדן הפיצ'ר כולו. אם אני צריך לפתח מערכת Serverless על אמזון ואני לא מכיר בכלל את העבודה עם אמזון, אני יכול לבלות עכשיו שבועות בללמוד איך עובד מנגנון ה IAM שלהם ומה חוקי אבטחת המידע שאני צריך. אבל אז אני אמצא את עצמי חודשיים וחצי לתוך הפיתוח כשעוד לא התחלתי לבנות שום דבר שמנהל המוצר או המשתמשים שלי יכולים לראות, ובהרבה מערכות סיפור כזה יכול לקבור לגמרי את הפיצ'ר כי העולם יזרוק דברים יותר חשובים לכיוון שלכם.
הערכת זמנים טובה, התייעצות ויותר מחשבה על סדר הפיתוח יכולים לעשות פלאים לתהליך הפיתוח אצלכם, גם אם בסוף הפיצ'ר יראה בדיוק אותו דבר.