135 final class 17 Software Deadlines

להלן פרוטוקול ישיבת הוועדה המסדרת שנערכה ביום שני ה-23 באפריל. נוכחים: יו"ר רן תבורי, סיו"ר אורי להב, וכן ראשי הסניפים ערן הראל, יונתן, ארז מזור, איתי ממן, ישי סמית'. גם גילי בא. על הפרק היום: דד-ליין בעולם התוכנה. הערכות זמנים, בדומה לתכניות עסקיות של סטארטאפים, הן תת-ז'אנר בסוגת המדע הבדיוני, מאוד תלוי כמה המתכנת רוצה לבצע את המשימה וכמה היא מעניינת. בכל מקרה - לא טריוויאלי. ישנן כל מיני שיטות להעריך זמני ביצוע: לתת שלושה זמנים (נמוך, צפוי, ארוך), לתת הערכה של הזמן ואז להוסיף פקטור כלשהו (30 אחוז, כפול שתיים וכו'). צעירים משלמים כפול - פה זה לא סלקום. גם ב-Quora שאלו. בקצרה, המרחק בין סן-פרנסיסקו ללוס אנג'לס הוא לא בדיוק מה שנראה בהסתכלות ראשונית. האם חוסר היכולת להעריך זמנים נובע מחוסר בגרות של המקצוע ? חוסר מקצועיות של המתכנתים ? כל פרויקט תוכנה הוא ייחודי, גם אם יש לו מאפיינים דומים לפרוייקטים אחרים. לעומת תחומי הנדסה אחרים, העלות של טעות בתוכנה היא לא קטסטרופאלית ולכן אפשר להרשות לעצמנו לטעות. מה עושים עם דד-ליין שבאמת - אבל באמת - קשה להזיז ? נגיד, יום שבו יהיה ליקוי ירח? משולש הזהב הוא משאב-תוכן-איכות, כנראה שהתוכן ייפגע אם הדד-ליין מתקרב. ההגדרה של מה נכנס ומה לא למוצר עד הדד-ליין הוא פונקציה של מה מטרת הדד-ליין (לבדוק היתכנות, A/B testing, להשוויץ בעומסים הגבוהים שאפשר לעמוד בהם וכו'). כדי לעמוד בדדליין, לפעמים חותכים פינות (קוד ספגטי, פחות עמיד וכו'). החוכמה היא לתקן את מה שמקולקל (או שדורש שיפור) בהמשך. ומה עושים עם מתכנתים שלא נותנים הערכות זמנים ? מחלקים לחתיכות קטנות יותר ומעריכים אותן (לדוגמה). בני אדם נוטים לצרוך את כל הזמן שהוקצה לביצוע משימה. מישהו כבר אמר את זה קודם. הערכות זמנים לא מתאימות לכל אחד, יש כאלה שזה יעשה להם רע - ולהיפך. אורי מדבר על יק. ועל סכיני גילוח. ועל גילוחים. מחלקה סגורה כבר אמרנו ? הערכות זמנים יכולות לשמש להערכה של הכדאיות העסקית של העבודה. דדליין יכול להכניס אנשים ללחץ. כן, זה קורה. "Your lack of planning is not my emergency". לחן - עממי. וגם: אם הכול הוא חירום, אז בעצם שום דבר הוא לא חירום. אוהבים תכנות ? מתכננים קריירה בתחום ? נהדר. יש לכם 40 שנה לעשות את זה, תעשו את זה בכיף, קחו את הזמן. קנת בק אמר (גם) את זה. למנהלים יש חומר קריאה מיוחד. אחת המסקנות - תן למתכנת לקבוע את הדדליין. מה שיכול להניע אנשים לקצר את לוחות הזמנים הוא הידיעה שמעט אחרי שהקוד ייכנס מישהו (ובשאיפה - הרבה אנשים) ישתמש בקוד. אנשים שונים מייצרים פיתרון שונה לאותה בעיה ולכן הערכת הזמן תלויה מאוד באדם שיממש בסופו של דבר. דדליין זה כמו חסה: בריא לאללה - אבל לאכול את זה כל יום בצהריים ?! קצרצרים: חמשת השלבים של דיבוג. בקאנדס למיניהם: למובייל: parse, usergrid, cocoafish, cloudmine, kinvey, stackmob, mobdb לריל טיים ווב: meteor, derby, firebase שני פודקאסטים חדשים: למבדה פוד ותירו בי יש סטטיסטיקות של רברסים. ג'ון סקיט - כבוד. הערת המשורר: אם לא קראתם עד עכשיו, לכו ותקראו מה הם חמשת הנושאים בראש רשימת ה-TODO של פול גראהם. הקובץ נמצא כאן האזנה נעימה ותודה למשורר יותם אורון :)