Joel on Software   יואל על תוכנה

מאמרים שתורגמו לעברית

גרסה אנגלית

כתבו למחבר

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

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

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

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

1. האם אתם משתמשים במערכת בקרת תצורה (Source Control)?
השתמשתי במערכות מסחריות, והשתמשתי ב- CVS, שהיא בחינם, ואני אומר לכם,CVS היא בסדר גמור. אבל אם אין לכם מערכת בקרת תצורה בכלל, תתאמצו מאד לגרום למתכנתים לעבוד כקבוצה. המתכנתים לא יודעים מה עמיתיהם עשו. לא ניתן לסגת משגיאות בקלות. עוד יתרון כשמיישמים מערכות בקרת תצורה - כל הקוד נמצא על הכוננים של כל המתכנתים - לעולם לא שמעתי על פרויקט שהשתמש בבקרת תצורה ואיבד הרבה קוד.

2. האם אתם מסוגלים לבנות גרסה בצעד אחד?
כלומר: כמה צעדים נדרשים על מנת לבנות מוצר מושלם מתמונת קוד עדכנית? בקבוצות טובות, קיים סקריפט יחיד אשר מביא את כל הקוד מבקרת התצורה "מנקי", בונה מחדש כל שורת קוד, מכין את כל ה- EXE, בכל התצורות, שפות וצירופי ifdef#, יוצר את חבילות ההתקנה ויוצר את המדיות הסופיות - תמונת CDROM, אתר הורדות, וכו'.

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

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

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

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

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

קראו עוד על כך במאמרי Daily Builds are Your Friend.

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

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

• הצעדים המדוייקים לשחזור הבאג
• ההתנהגות הצפויה
• ההתנהגות הנצפית (השגויה)
• למי הבאג משויך
• האם הוא תוקן או לא

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

עבור מידע נוסף על מעקב באגים, קראו את Painless Bug Tracking.

5. האם אתם מתקנים באגים לפני כתיבת קוד חדש?
הגרסה הראשונה של Microsoft Word for Windows נחשבה פרויקט "מצעד המוות". הוא לקח נצח. הוא נדחה עוד ועוד. הקבוצה כולה עבדה שעות מטורפות והפרויקט נדחה שוב ושוב והלחץ היה נוראי. כאשר הדבר הארור נגמר שנים מאוחר יותר, מיקרוסופט שלחה את כל הקבוצה לנופש בקאנקון, וישבה לעשות חשבון נפש רציני.

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

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

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

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

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

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

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

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

זו סיבה אחת לתקן באגים מיידית: כי זה לוקח פחות זמן. יש סיבה נוספת הקשורה לעובדה שיותר קל לחזות כמה זמן יקח לפתח קוד חדש מאשר לתקן באג קיים. לדוגמה, אם אבקש ממכם לחזות כמה זמן יקח לכתוב קוד למיון רשימה, תוכלו לתת לי אומדן לא רע. אבל אם אבקש ממכם לחזות כמה זמן יקח לתקן באג בו הקוד שלכם אינו עובד אם Internet Explorer 5.5 מותקן, לא תוכלו אפילו לנחש, כי אין לכם מושג (הגדרתית) מה גורם לבעיה. זה יכול לקחת 3 ימים או זה יכול לקחת 2 דקות.

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

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

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

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

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

תחזוקת לוחות זמנים אינה חייבת להיות מסובכת. קרא את מאמרי Painless Software Schedules, אשר מתאר דרך פשוטה לבניית לוחות זמנים נהדרים.

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

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

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

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

לימדו הכל על כתיבת מפרטים על ידי קריאת הסדרה בת 4 פרקים שלי.

8. האם יש למתכנתים סביבת עבודה שקטה?
מתועדים בספרות תוספות פריון רבים שניתן להשיג על ידי מתן תנאי סביבה, שקט ופרטיות לעובדים. הספר הקלאסי Peopleware בנושא ניהול תוכנה סוקר תרומות אלו ביסודיות.

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

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

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

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

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

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

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

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

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

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

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

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

10. האם יש לכם בודקים?
אם אין לכם בקבוצה בודקים יעודיים, לפחות אחד לכל שניים שלושה מתכנתים, אתם מספקים מוצרים מלאי באגים או שאתם מבזבזים כסף על ידי שימוש במתכנתים שעלותם 100$ לשעה לעשות עבודה שיכולה להתבצע על ידי בודקים ב- 30$ לשעה. התקמצנות על בודקים היא חשבון כלכלי כל כך עקום שאני פשוט לא מסוגל להבין מדוע אנשים נוספים לא מבחינים בכך.

קראו את Top Five (Wrong) Reasons You Don't Have Testers, מאמר שכתבתי על נושא זה.

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

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

למרות זאת, בכל יום, מתכנתים מתקבלים לעבודה על בסיס קורות חיים מרשימים או כי המראיין נהנה לשוחח עימם. או ששואלים אותם שאלות טריוויה ("מה ההבדל בין CreateDialog ו-DialogBox?") אשר ניתן לענות עליהן על ידי הסתכלות בתיעוד. לא אכפת לכם אם הם שיננו אלפי טריוויה על תכנות. אכפת לכם האם הם יודעים לכתוב קוד. לחליפין, אפילו יותר גרוע, הם נשאלים שאלות "אהה!": סוג השאלות אשר נראות פשוטות אם יודעים את התשובה, אבל אם לא יודעים אותה הן בלתי אפשריות.

בבקשה, הפסיקו לעשות זאת. עשו מה שתרצו במהלך הראיון, אבל בקשו מהמוראיין לכתוב קצת קוד. (לעצות נוספות, קראו את מאמרי Guerrilla Guide to Interviewing.)

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

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

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

ארבע דרכים להשתמש במבחן יואל

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