פרות, חיות בר, והשיטה המדעית

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

-

ב 2011, רנדי באייס הציע את האנלוגיה של חיות מחמד לעומת עדר בקר כדי לחדד את ההבדלים בין שרתים מסורתיים וארכיטקטורת ענן. הוא ניסח את זה בערך ככה (התרגום שלי):
״…למשל בוב שרת הדואר. אם בוב נופל, מזעיקים את כולם. המנכ״ל לא יכול לקבל את האימיילים שלו וזה סוף העולם. בדרך החדשה, שרתים ממוספרים כמו עדר בקר. למשל www001 עד www100. אם אחד מהשרתים נופל, לוקחים אותו הצידה, יורים בו, ואחד אחר לוקח את מקומו.״
הסגנון והאנלוגיה לא התיישנו טוב, אבל לתקופתה, האנלוגיה הזו הסבירה יפה מעבר מהנדסה שמגינה על פרטים לארכיטקטורה שמנהלת אוכלוסיות.

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

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

---

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

New York City traffic and the future of software development

 It is a truth universally acknowledged that code expands to fill the available capacity to debug it. We’ll get back to software in a minute, but let’s talk about a man first.

Robert Moses was a uniquely powerful, smart, and corrupt figure in mid-20th-century New York City and New York State. He was an unbelievably prolific builder who channeled various public and private resources into the parkways, beaches, and bridges of the New York metropolitan area by every means possible. He had no problem lying, ruining people’s lives, and upending communities if it served his purposes. Under his leadership, the city gained many more roads that were wider and better. It had more bridges connecting various parts of the city. It had more parkways.

Robert Moses and his subordinates believed that all this would alleviate the traffic problems the city was already experiencing with the mass production of cars. To their surprise, as they built more roads, more cars seemed to pop up. This offset the change in capacity and left congestion unchanged. They initially believed this to be a good sign. It meant that many people were suddenly able to use the roads, and they assumed the eventual result would be a smoother flow of traffic.

They were wrong.

More roads, they learned slowly, meant more, not less, traffic. This was counterintuitive at the time, but it is well understood today that this is how traffic in heavily populated areas works. It becomes congested up to a point, and adding roads provides a very temporary solution to the problem, if that.

Academics caught wind of this phenomenon and felt the immediate need to name it. Around 1962, economist Anthony Downs formulated "Downs's Law of Peak-Hour Traffic Congestion." By the '90s, the general case became known as induced demand.

For some things, it seemed, increasing the underlying resource’s availability is never enough.

Fast forward to emerging software development patterns in light of advances in AI. We appear to be more efficient and more productive. We need fewer people to do the same job, and we do it faster than ever. We generate code. More and more code.

The more code we generate, the more bugs there are in the world. The more bugs we find, the more work these code-generating machines will have. To fix them, they will generate more code, and round and round it goes. Therefore, in this software engineer’s opinion, reports of our profession’s death have been greatly exaggerated. The industry overall will end up needing similar numbers of people. The increase in efficiency we currently feel will soon be squashed under masses of code piling ever higher and deeper. There will always be just one last bug to solve, for which the AI apologizes humbly. "It was indeed an oversight on my part," it will say. "I will fix it immediately. Is there anything else you’d like to talk about?"