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