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

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

המחשב הראשון שלי היה קומודור 64. כמעט 30 קילו-בייט של זיכרון RAM נועד למערכת, והשאיר 32 קילו-בייט לעיבוד תמלילים, גיימינג, חשבונאות עסקית משפחתית וכמעט כל מה שאני עושה עם המחשב בגודל 6 ג'יגה-בייט. זה משאיר את השאלה פתוחה האם הציוד של ימינו עונה לצרכי התוכנה או שהתוכנה משתמשת במשאבי חומרה רבים יותר מכיוון שהם זמינים?

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

להלן הסיבות.

חוק זאווינסקי

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

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

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

העיקרון של פיטר חל על תוכנה

לורנס פיטר התפרסם בכך שקבע כי בהיררכיה אדם עולה לעמדה שהוא לא כשיר לגדול. אבל הוא גם הספיק לומר משהו על פרויקטים מורכבים:

"פרויקט מורכב יהפוך למורכב מכדי שיוכלו להבין אותו אפילו על ידי היזמים שלו."

עיקרון הכי פחות תמהון

פורסם בכתב העת IBM Systems בשנת 1984, עיקרון זה קובע כי:

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

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

חבל ששאטלוורת 'לא לקחה את זה בחשבון כשהשיקה את יוניטי.

חוק אנטומולוגיה קיברנטית

הבאג הראשון בתולדות המחשבים היה אמיתי. עש התעופף לאחד הממסרים במחשב MARK II שגרם לתקלה.

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

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

חוק קרניגן

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

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

מכאן החוק של קרניגן קובע כי:

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

כלל 90/90

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

לעולם המחשבים יש גרסאות של החוק הזה. לדוגמה, טום קרגיל אחד אמר:

"90 האחוזים הראשונים של הקוד מייצגים את 90 האחוזים הראשונים של זמן הפיתוח. 10 האחוזים הנותרים של הקוד מייצגים את 90 האחוזים האחרים של זמן הפיתוח.

האם זה לא היה ברור? אולי החוק של הופשטטר יעזור:

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

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

חוק ברוק

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

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

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

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