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

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

לאחרונה קיבלתי לוח פיתוח של TI לשבב עם יכולות WiFi, אחרי שהבעלים הקודמים התייאשו ממנו. כיוון שהלוח הוא יד שנייה, הקוד המקורי שהגיע עליו כבר נמחק, אז פניתי למשאבים המקוונים של TI כדי להתקין מחדש ולנסות את פרויקט ההדגמה שהם קוראים לו, כמה אירוני, Out-of-box.

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

השלב הבא הוא להתקין אפליקציה ייעודית של TI שיכולה לדבר עם הלוח. לתדהמתי האפליקציה עבדה… בדרך כלל. הטלפון כנראה קצת השתגע מזה שה-Hot spot המאולתר של הלוח לא נותן לו גישה לאינטרנט, והחליט להתנתק על דעת עצמו ולחפש רשתות אחרות, אבל בין לבין הצלחתי להדליק ולכבות את הלד שעל הלוח באמצעות לחצן על מסך הסלולרי. נהדר. עכשיו הגיע השלב החשוב באמת – לבצע provisioning, כלומר במקרה זה לדווח ללוח דרך האפליקציה איך הוא עצמו יכול להתחבר לרשת ה-WiFi הכללית בבית, כדי לשלוח מידע לענן וכאלה. את זה לא הצלחתי בשום פנים לבצע: האפליקציה לא הצליחה לאתר את הלוח כמכשיר שאפשר לעשות לו provisioning, וזהו. לכו תבינו עכשיו אם זו בעיה בקוד, בחומרה, באפליקציה, ב-WiFi או בזעמם של האלים. מיותר לציין שחיפוש ברשת לא העלה שום פתרון.

אני מקבל את זה ש-WiFi יכול להיות דבר מסובך, למעשה אני נדהם בכל פעם שמשהו אלחוטי-ענני כזה כן עובד. אבל ריבונו של עולם, אתם חברה שמרוויחה מיליארדי דולרים בשנה, יצרתם לוח פיתוח שלם להדגמה של הרכיב החדש, כתבתם אפליקציה, כתבתם קוד out-of-the-box כדי להראות לאנשים כמה זה קל ולשכנע אותם לעבוד עם השבב שלכם ולא של המתחרים… לא נראה לכם הגיוני לדאוג שהוא גם אשכרה יעבוד? אולי פשוט תוסיפו לערכה גם מזלג קטן שכדי אוכל לתקוע לעצמי בעין?

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

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