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

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

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

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

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

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