לעניות דעתי In my humble opinion

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

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

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

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

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

אז למה שמתי לב בזמן ששיחקתי במשחק הזה?

1. היה לי הרבה יותר קל לשחק במשחק הזה מאשר לאחרים, כי ידעתי שאני מתכנת, ויש לי ניסיון מסוים בתכנות. 
2. תוך כדי משחק, הרגשתי בחסרונן של כמה פקודות בסיסיות מאוד - כן, זה הרבה יותר פשוט לתכנת את המשחק אם שומרים את סט הפקודות בסיסי, ואפשר בהחלט לעשות כך הכל - אבל זה כל כך מתיש! אם אני כותב באסמבלי, למה אני לא יכול לקפוץ לשורה בתוך הקוד כדי ליצור לעצמי פונקציות? כתוצאה מכך, הקוד שכתבתי היה משמעותית פחות יפה מאשר רציתי שיהיה (כי בשביל קוד יפה הייתי זקוק לפונקציות, או לפקודת "קפוץ אם גדול מאפס", למשל). 
3. ומילא פקודות חסרות - הייתה פונקציה אחת שהרגיזה אותי במיוחד - המשחק מאפשר לכתוב תוויות - גם על שמות של משתנים (בלוקים על הרצפה) וגם לפני חלקים בקוד (ממש כמו תוויות באסמבלי). לכאורה - אחלה! בפועל, כדי לכתוב תווית נאלצתי לצייר אותה בעזרת העכבר. לכתוב בעזרת המקלדת? לא ולא. אז מה אם זה לוקח לי פי עשרה יותר זמן?
4. כשהבעיות הסתבכו, הממשק הגרפי הידידותי להפליא בעיקר הפריע - כשהקוד הנדרש היה ארוך, או אם רציתי לנסות ולשפץ את הפיתרון כדי להצליח להגיע לאתגרים הספציפיים - פשוט פתחתי notepad וכתבתי את התוכנה שם. כל ההתעסקות הזו עם חיצים שזזים ממקום למקום בעיקר סיבכה את העין והסיחה את דעתי. 
5. ככה שמתי לב שלוקח לי הרבה פחות זמן לכתוב את התוכנה שלי מחוץ למשחק. גם בלי בזבוז הזמן על התוויות, לגרור משהו למקום הנכון (ובמקרה של פקודות "קפוץ ל...", לגרור שני דברים) פשוט לוקח הרבה יותר זמן מאשר לכתוב את הפקודה הרצוייה.

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

1. למתכנתים יהיה קל יותר להפעיל תוכנות כאלה. בסופו של יום, עיקר ההבדל בין מתכנת לבין מי שאינו מתכנת הוא בהבנה של איך כותבים אלגוריתם - וגם אם גוררים ציורים יפים פה ושם, הם צריכים להתנהג כמו תוכנה. אפשר לרכוש מיומנות גם בלי רקע בתכנות, אבל זה רק אומר שלומדים לתכנת תוך כדי עבודה. 
2. "קוד" שנכתב בעזרת כלי כזה לעולם יהיה פחות אלגנטי ופחות יעיל מקוד שנכתב בשפת תכנות מלאה - כדי לשמור על דברים פשוטים יחסית, התוכנה תאפשר סט פעולות מצומצם יותר. אפילו אם אפשר יהיה לשמור קטעי קוד בתוך התוכנה (SoapUI מאפשרת להכניס קוד groovy, אם אני זוכר נכון) - עדיין יהיה מדובר בקטעי קוד מבודדים, עם ממשק מוגבל להעברת נתונים בין קטעי קוד. 
3. לכל כלי גרפי יהיו המוזרויות שלו - דברים שהמפתחים החליטו שצריכים להתנהג בצורה מסויימת, ולמשתמש אין מה לעשות חוץ מאשר להתרגל. כן, זה כך גם בשפות תכנות, אבל בממשק גרפי זה מורגש יותר ומגביל יותר. 
4. ממשקים גרפיים מוספים רעש ומפריעים למוח להתמקד בבעיה. אם בשפת תכנות אני יכול להוציא את קטע הקוד בו אני מתמקד לפונקציה נפרדת או למחלקה חדשה בתוך חמש שניות - טרם נתקלתי בממשק גרפי שמאפשר לי גמישות שכזו, ובחלק גדול מהם -גם אם הצלחתי לבודד את הקטע בו אני רוצה להתמקד, השאר יהיו שם כדי לעשות לי רעש בעיניים או להחביא מידע חשוב מאחורי רשימות מתקפלות. 
5. תכנות דרך ממשק גרפי הוא יקר באופן משמעותי בהשוואה לתכנות בטקסט. 

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

Not very long ago I came, via humble bundle, across a game called "Human Resource Machine". It's a game I've noticed quite a while ago, but decided that while 10$ isn't much at all, it is still more than I'm willing to pay for what would probably be a fairly short amusement with almost no challenge. So, since humble bundle offers a "pay what you wish", I bought this game (alongside two or three other games I won't even install on my PC, not to mention play) at tenth of the usual price of the game. 

In case you skipped the video in the link above, the way the game goes is as follows -  Each level looks the same: there's an input queue, an output queue, a work floor and a place to write instructions. Only two things change between levels: the possible inputs in the queue, and the required output. For example, one level might be "move only the even numbers to the output queue and discard the rest" and another might be "for each number in the input, output all Fibonacci numbers that are not bigger than it. (so, for the input "10", output 1,1,2,3,5,8). In order to achieve this goal, you have a set of up to 11 possible commands: take from inbox, put in outbox, copy to a tile in the work-floor, copy from a tile, increase a tile by 1, decrease a tile by 1, subtract, add, jump to command, jump if zero, jump if negative. 

Those of you who have seen an assembly code once or twice in their life can surely see the similarity. The rest - trust me, it's a fully capable assembly programming language. 

The game itself is quite nice, and optimizing the solutions for the higher levels is a bit of a challenge even to someone with formal CS background and a bit of university-level experience in assembly such as myself (I'm assuming it wouldn't be any problem for those with some practical experience with assembly), but it made me think about the plethora of tools meant to provide non-programming testers with automation capabilities.

How did I get from playing a game to thinking about commercial, sometimes very powerful tools? Well, the basic goal is the same - to have people programming without noticing this is what they do. I think we can learn something about those tools by looking at the game and projecting this on the click-programming tools.

1. I had it much easier than others. I knew I was programming and I was familiar with assembly. 
2. While playing, I strongly felt the need of certain basic commands. True, it is simpler to program the game while keeping the instruction-set to a minimal, and everything can be done this way - but this is so very much more frustrating this way. Why couldn't I jump to a line in my code? or even better, have a "call function" functionality? As a result, the code I had in the game was not as clean as I would like it to be - there's a limitation to what I could do without functions, or even a "jump if greater" command. 
3. On top of the missing instructions, I found one existing, and quite needed feature to be extremely annoying. It was the labeling mechanism.The game allows for creation of labels by drawing pictures on a limited space. Both pieces of code and tiles on the work-floor can be labeled. However, the process of creating a label required me to doodle a word using the mouse. Writing with the keyboard? nope. So i spent about 30 seconds drawing "first" instead of typing it in two. In the cases I skipped using labels, I ended up confusing myself. 
4. When I got to the more complex problems, especially to those requiring long code, or those where I didn't manage to optimize the solution easily, I wrote my program in notepad++ before copying it to the GUI. Messing around with dragging and dropping commands, placing them properly (with jump commands requiring two such actions!), was taking me too long to properly think. Moreover - I couldn't think properly when looking at the spaghetti code I had. One can't really write assembly code without jumping, since every "if" statement is jumping somewhere, but with the GUI I could see the lines intersecting, and most of the times had to scroll up or down in order to see where I was jumping to or from. Processing the information from the GUI took more thinking resources from me than sorting out the algorithm in a clean textual way. 
5. by writing stuff in notepad I noticed that even when I knew what I should do and did not have to stop thinking, writing code was tenfold faster than dragging stuff in the GUI. Even without the labels mess - working with the mouse is that much slower than typing. 

All of those points are, to some extent, relevant to all "you don't need to be a programmer" tools. and here's how I try to generalize them: 

1.   Even with those programs, programmers will have an easier time generating more valuable product. The concepts of code reuse, being able to design an algorithm to solve a problem and the rest of the programming shticks really apply to this type of programming as well - not everything is feasible in every tool, but programming with a  GUI is still programming. 
2. "Code" written with such tools will, most of the time, be less pretty than proper code written in a proper programming language. If the tool is really good, most of the mess will be hidden under the carpet and the developer working with this tool won't notice the mess, or it would be quite expensive to design and implement a framework that will be cleaner. Even when one have the ability to write code snippets, moving data between code snippets will be limited to the way chosen by the tool. Making the tool itself communicate with your code snippet is even more limited - could I return an error code from a snippet that will direct the choice of the next step performed by the tool? The tool can parse only the interface chosen for it. 
3.  Every graphic tool will have its own quirks - missing functionality, hidden stuff, common actions that take 5 clicks to perform or even simply doing things in a certain way, and the users can only grind their teeth and get used to it. It is also true for any programming language (really, Python? white spaces are syntax??), but in a GUI those nuisances are more present and a whole lot more annoying. 
4. Graphic user interfaces add a whole lot of noise that interferes with engaging the programmatic problem. In any decent IDE I can take a problematic piece of code I want to focus on and extract it to a method or to a new class in less than five seconds, where I can then look only at the code I want to think about. I have yet to see a graphic tool that enables this.
   And even if there is something equivalent - all of those graphic hints ("this is a data source", "this is a piece of code", "this is an assertion") still require some brain power to parse. Yes, it gets better as one gets used to the graphic language, but my guess is that it still requires more than simply reading text. 
5. Programming through a GUI is way more expensive than using text. 

So, what am i saying, that such tools are useless? That everyone should just learn to program and write their own code? While tempting - that's not what I say. Those tools (at least the good ones) do serve a purpose, and for that purpose they do very well - a non-programmer can definitely benefit from them, and even for a programmer, they tend to save quite a while of setting up your own infrastructure.

What I am saying, though, is that those tools, shiny as they may be, contain a rotten core - some fundamental limitation that will punish you some day. It might be an explosion of hard to manage "scenarios" (or "suites", or whatever), it might be that you'll start building large objects that will make the tool UI slow, or it might only be the fact that you get to the point where you have exhausted the potential of the tool, and now you can't augment it (or it is really hard to augment and you waste a lot of time finding a workaround). But, as this bite might not be that bad, it does make sense, in some cases, to use such a tool. However, when you do consider choosing such a tool, take its promises with a pinch of salt, and be aware of what you are losing, not only what you  might gain. 

Besides, this game is quite cute.