Sunday, February 17, 2019

ETC 2019 - day 1

Source: Sarah J. Wells keynote slides

So, European Testing Conference 2019 is officially done, and what a blast it was.
There's so much that went on, so I'll start with a short summary - I got to meet and connect with great people - some of which I've met before, others I met for the first time. Selecting which content I wanted to listen to was harder than ever as the talks topics was superb and I got out with a few insights from both official content and just talking to people. If you weren't there - your loss, and you should remedy this next year.

A tiny tip for conferences - if you can, stay at the conference hotel (Sometimes it's official, in other times it's just the hotel closest to to conference) as it will enable you to have a little bit more time to connect with people over breakfast. I started my first morning with a short chat with Alina Ionescu, which apart from being a pretty cool person in and of herself is also part of the team that created ETC (and if my memory serves me well, has been doing this in the past 4 years as well). We didn't have a lot of time to chat because mornings are hard, and she had to go and organise some last things at the conference venue, but it was still a pleasurable start of the day.
I took a bit longer and got in time for registration, managed to say hi to some familiar faces and went to listen to the opening keynote by Angie Jones. Angie's talk has been quite different from my expectations, in a very good way. The talk was a story of a challenge that was just too much to overcome and the problem remained unsolved. The full talk will be online somewhere in the (I hope near) future, but I took from it a couple of things:
First of all, it was a reminder that culture is stronger than any single person, no matter how talented or creative they are. Second, there isn't yet any constructive way of speaking about testability - what it is and how to approach it. As for now, the best attempt I've seen is the 10 Ps model (There's probably a better link somewhere, I didn't find one) which is a great way to expand many aspect of it, but still very abstract in nature. All in all, it was a thought provoking keynote. Just the right way to kick-off a conference.
We then moved to the second building - the venue was, sadly, split in a manner that required getting out to the street to get from one part to the other. Normally I would assume that this is a major setback that will interfere with connecting people, but the organising team proved once again that when's there a will, there's a way, and I didn't see any such effects. In fact, their choice to leave the central auditorium empty during regular session time provided a very nice place to sit and speak with someone when we needed some quiet from the crowd. Anyway, back to the session. I went to a talk about contract testing for a microservice environment. It was a very good talk for me, since it dealt with a problem-space close to me, and presented an intricate implementation of an idea that I need to investigate a bit further. I'm not sure I understood exactly how is the mechanism works and where exactly it it beneficial to apply contract testing, but every talk that leaves me with some homework to do is a good one.
Then - running back for speed meet. This format is tough, and I like that the organisers still experiment with it. On one hand, it's a great way to create some new familiar faces and break the ice in a safe environment. On the other, it's very loud and crowded, easily creating sensory overload and easily  draining a lot of energy from introverts and ambiverts. This has made the announcement at the beginning ("If at any time you feel you want to leave, just do so") very important. I liked the standing-up setup we had this year - no more fussing with chairs, and the acoustics of the hall made it a bit less noisy than last year, even though there were more attendees (I think). There are still things I think we can improve - Slowing down and providing a bit more than a minute is one thing I might consider - meeting 20 new faces in quick succession is great, but that can be a lot, and one minute is very difficult to manage. Second, I wonder about the mind maps - it's just too easy to hide behind them instead of having a short conversation, perhaps a more condensed format (such as "three words related to you") will be more effective in creating some face-to-face conversation and not face-to-paper one. Still, despite everything, the main goal is clearly working - after the speed meet there are a lot of new familiar faces, and the choice to make it just before lunch is nothing short of genius, to allow people to continue conversations in a more relaxed situation.
I skipped the next track of sessions - and instead sat to speak with Kristine about SpeakEasy (I ended up agreeing to help two new mentees,  which is rather cool). Then we moved again to lean coffee - my favorite activity by far - and then the closing keynote for that day.
Sarah J. Welles told a fascinating story about the challenges and insights we face when working in a fast-releasing environment. For instance, did you know that some sharks really like the taste of the Vietnamese internet cables? This talk, like other CD tales I've heard in the past, left me thinking about what can be taken from those systems to a higher risk, slightly higher regulated environment and what would be the stepping stones in the way. Slow & big releases are painful.

A closing keynote means end of the day, right? Not in ETC. There was a conference party\dinner\something going on. There was food, there were people, there was time to chat and process. I got to speak with new people and had time to speak with some friends as well. Somehow it just happened that I found myself so immersed in a conversation that I didn't notice there were closing the venue, When we did notice that we simply moved to speak in a nearby tapas bar - it was not that we were hungry, but rather just wanted to continue talking. By 23:00 we decided that the smart thing to do would actually be to go to sleep. So we went to our hotels.
Well, remember what I've said about using the conference hotel to extend the conference? I saw some people sitting in the lobby and thought "I can say hi for a couple of minutes".
90 minutes later we called it a night and went to sleep.

This ended my first ETC day - fully packed and positively exhausting.

Thursday, February 14, 2019

ETC 2019, day 0

So, it's ETC time of the year again, this time in Valencia.
As usual, I took a couple of days to get to know the area and do some touristy stuff.
I got here by Monday evening, dropped my bags at the hotel and went for a short tour around to get a feeling of direction and of the environment. One thing I've noticed here is that people around here don't English well. Or, in fact, almost at all - The little time I've spent using Duolingo was sort of paying off when I could tell people "I'm sorry, I don't speak Spanish" (Or, in the short version: "Excuse me, English?")
Anyway, I found something to eat and went to sleep a while.
Tuesday was when my plan actually started. When travelling I always have the same plan: Walk until My feet fall off, and then some.
I started with a walking tour, which gives me both the opportunity to walk around a bit and to make a quick checklist of interesting things. For example, one thing I've learned is that a bat and a dragon are, essentially, the same thing. At least in Heraldry, both signify protection, and since it is easier to draw a bat in a frontal position (or maybe, because when you draw a dragon in that position it looks very much like a bat) then the two of those are kinda merged, and one can see how over time a front facing dragon will turn to be a bat. So, if you ever wondered why does Valencia have a bat as part of it's shield - now you know.
Another thing I got from the trip is a recommendation to try a local drink called "horchata", with the warning that either you like it, or you really don't. Apparently, I really don't. The other beverage that was mentioned, which is an alcoholic one, is "agua de Valencia" (Valencia's water) which is a nice cocktail that has the important property of not tasting like strong alcohol.
After the tour I wandered a bit more, found a place where I could buy a charger for my computer to replace the one I forgot back at home  (Well, almost, my laptop is a monster requires 170W and the strongest they had was 120W, which is enough to keep my computer from draining and charge it while it's off) and then I went to climb the stairs of Micalet, a bell-tower with a nice view of the city roofs. Micalet which is Valencian (A language that is still taught at schools in the region) for "little Michael" (I think that in Spanish it's "El Miguelte"). The bell itself is little in the same sense that little John is - It's a heavy metallic monster, the biggest in the area.
After climbing those 207 narrow stairs, and then down, I relaxed a bit by going to the ceramic museum - Some nice things in exhibition, but I was hoping for some more detailed explanations or a coherent story or something. Still, a nice place to be in.
Dinner, then sleep.
Wednesday I started by walking through the park from my hotel in city center to the Science museum near the beach. It's a nice park, and the walk was a leisurely paced stroll of ~30 minutes, so I enjoyed it a lot. The science museum was rather nice, even if some exhibitions were being disassembled. I went out feeling that it's a nice start, but can be a bit more. As I was already there, I took a trip to the oceanografic -Basically, an aquarium. I made a mistake and assumed that since it was partnering with several projects aimed for ocean preservation it won't be one of those aquariums that is essentially a zoo - holding many marine species out of their context (there's a nice one in Vancouver where they treat animal and try to restore as many as possible to nature). Visiting there didn't seem like it was doing anything like that, so in retrospective I should have checked more thoroughly. It also can be that I got a false impression, so if you care about those things and consider going to the Oceanografic, do your research better than I did.
After the visit I strolled towards the beach, where I stumbled upon Lisa Crispin who introduced me to the rest of the gang that was hanging out there. I ended up walking back to the hotel with Kristine and we had an adventure trying to figure out the city-bike rental scheme. We didn't manage to do that and settled on a bus, but it was a lot of fun nonetheless. Naturally, we didn't go straight back to the hotel, but stopped to meet a bunch of people for dinner. So, in a manner of speaking, the conference has begun.
So,  Happy ETC to everyone!

Saturday, January 12, 2019

שייחנק הלקוח

English version

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

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

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

Eff the user

This idea has been running in my head for a while, and every so often I'll stumble upon a reminder to write something about it, and then have other things to occupy me. The most recent trigger was a talk by Joel Montvelisky in a local SIGiST conference where he spoke about the changing role of the testers. The subject is my objection to one of the modern testing principles.  I'll admit - I really like them. That is, with the exception of principle #5: "We believe that the customer is the only one capable to judge and evaluate the quality of our product".
I don't like this one a tiny single bit. I think it's a false statement and it drives wrong team behaviour and goal displacement. Worse, this idea seems to be ubiquitous in the industry, or at least wildly spread, as some of the variants of similar ideas out there show. I think that #5 is one of the most carefully worded expressions of this idea (as one cannot dismiss it with "a tester can't be a customer proxy\champion\advocate") So I'll stick with it when thinking through my disagreement. 
On the face of it, the principle is very solid - if we accept Jerry Weinberg's notion of quality being value to some person (and I like Bach's addendum to it), it only makes sense that the person who is getting the value is the best judge of it. 
Except when they aren't.
I am not claiming here that a product that is not used or bought by any of its target audience can claim to be "of high quality", but simply that there are cases where evaluating the quality of a product is something that the customer is not capable of doing. 
Imagine that you are getting an OS update to your phone. It improves memory management, fixes a security flaw and provides better logging in cases of a crash. Are you in any position to evaluate any of this? Would an average phone user be in such position? All of it brings value - better logging means faster debugging cycles and faster hotfix releases, a security update reduces the likelihood of the phone being hacked and the memory management improvement will mean you could run more applications in parallel and avoid lagging. But how do you even notice any of those? You don't see the crash reports (and there are other ways to improve response time), the security update is like an insurance - you only notice it if something bad happens, and  your phone has enough memory that you didn't notice any problem with the previous memory management scheme. In all of those examples, there are simply too many layers of indirection between the actual property and the perceivable result and the quality of the product, if assessed by the customer, must be assessed by a proxy measurement. In some cases, the customer might notice if you did a shitty job, but the distinction between "barely good enough" and "excellent" is not visible. 
Then there's the ambiguity about "who is the customer". Consider a bug fix that eliminates a scenario where the user is charged for only 3/4 of the actual use. By fixing it, we are taking "value" from the product's user, but adding value to the vendor. While such condition is extreme, there are more examples when one looks on B2B products - The full disk encryption scheme used by our IT department makes our computers freeze for a second every now and then, but provides the decision makers (who don't use their PC as intensely as other employees do) the peace of mind knowing that data could not be leaked by simply stealing a PC. Customer value? high. User value - not so much.

Now, to goal displacement and wrong team behaviour. A simplistic understanding of this principle drives a lot of focused into perceived quality and requires advanced logic-fu to justify any kind of improvement that isn't a new feature. Take for example an architecture improvement for enabling our product to scale to need. We can go with the current architecture for a year or so, and probably throw more hardware on it for the next five years, so, no real benefit to the user, let's not do that. The rule-fu required would be something along these lines:  "If we don't do it then we can probably patch the system for 5 years but it will gradually slow us down as we deal with issues as they appear, and will also be exposing customers to issues caused by this load. In addition, in five years time we'll have more components relying on the old architecture we want to replace, so the change will take longer and be more risky and complex". This sort of logic is not trivial and far from immediate, if we train our instincts to zero in on the customer satisfaction we'll have a tough time coming up with such scenarios, let alone justify such future-looking actions in face of a well trained gut-feeling. Most teams don't need another thing applying pressure and bias towards perceivable features. True, if we insist, everything we do has an ultimate impact on the customer, but sometimes the impact of good engineering practices is several times removed from the actual impact, and it will usually be only one of the factors affecting that specific property of customer value. Imagine two similar SaaS products, both have the same capabilities, a similar size of customers and are distinguishable only by minor features that might appeal more to someone's personal taste. One product is built by a team of 10 highly skilled engineers that are running a tight ship. The 2nd is maintained by 100 people who work frantically to keep things afloat. The cost of operation for the two products is similar - The top notch engineers are getting payed 10 times as the less skilled ones, and the robust hardware and hosting services used by the first team are as expensive as the cost of throwing cheaper hardware  to gap for design problems in the second team. The perceived quality is the same, both companies can scale at roughly the same pace with roughly the same resources - is the quality of the two products equal? They are supplying the same customer value in different means, only the 2nd team is making it really difficult for their operations team.
I got a response for similar claim from Joel who said "The operations team are your customers as well".
Well, no.
Up until this point in the text we equated the development team to the company. By claiming that someone internal (be it operations, marketing or product management) is also a customer we are shifting our focus to the development team.
Let me say it clearly: As development team we don't have customers. We have employers and colleagues. Calling them "customers" might be useful when trying to convey the message that we provide a service to our colleagues and employers, but is otherwise causing confusion.  As employees we are getting a salary to promote the interests of our employer and that's it. I won't get a lower salary because my employer is unhappy with my work this month, and the contract between us have different obligations than those between a service provider and a customer. If I'm working towards my employer's interests it is time to face the cynical truth - most companies care about the customer only in terms of financial gain and a customer is nothing more than a walking bag of cash. Sure, it's very difficult to have a profitable product that does not align well with the customer's needs but when the two values are in conflict, I should be choosing the (long term) monetary1 business value over customer satisfaction.

So, Short version: Perceivable quality is not quality and it's important to remember that the customer is a (very important) mean to achieve our goals, but not the goal itself.

1 Thanks to Brent Jensen for reminding me that business value could be more than simply monetary. It's a bit harder to measure, and I believe it makes the point even more relevant - this business value could be the company's reputation, business contacts or even its moral values, for those fortunate enough to work in a company that cares about those

Monday, November 19, 2018

שמן נחשים להמונים

Snake oil for all


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

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

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

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

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

A couple of years ago we had an opening for another tester in our team and I found myself interviewing a lot of candidates. It was a bit long and very painful, but one of the candidates left a lingering impression. Like with most candidates, we've asked him to solve a simple coding problem on the whiteboard. How simple? Simple enough so that I asked my brother (who's programming background at the time was the stuff taught in high-school) to solve it, and he had no real difficulty with it. The candidate sat and thought about it. He pondered and considered and then contemplated a bit. Then, with an outburst of honesty said "look, I'm an automation person, I'm not a programmer".
We managed to keep a straight face.

The reason I recalled this now is that last week I stumbled upon an advertisement for a "introduction to automation workshop", free of charge, only two hours long. You know, the stuff that is usually done to sell a longer, pricey course that will teach someone "automation" from scratch. Normally  I see these things and fume silently. Those workshops have a constant format: You gather a bunch of people with no prior knowledge on coding, make them copy-paste some selenium commands in your language of choice and voilà! Automation! There are a million things wrong with this, but that's not what we're here for, since this time I changed my normal habit and asked the organiser to join. After all, what are a few hours of my time for the possibility to smear people on a founded basis?

However, as I was investing some time in it I decided I'll try to be fair and set some criteria according to which I'll pass my judgement. They are (in no particular order):

  1. Fair presentation of the workshop. One can only achieve so much in a two hours session, especially when assuming no prior knowledge. Making sure to explicitly say that and let people set realistic expectations is important.
  2. Is there a real advantage to attending the workshop over just going through some online tutorials?
  3. Respect to the profession (in this case - automation) - A sales pitch that conveys the message of "Automation is not that difficult, everyone can do it" will gain my contempt faster than one that will say "Automation is a complex task, let me help you do the first steps". 
  4. How much is the workshop geared towards sales? It is one thing to attend such an event when it is clear that it is only a taste of a bigger course, it is another to have the speaker mention it every other sentence and pushing it down the audience's throat. 
To start with the conclusion: I expected worse, so one might even say I was positively surprised. The workshop got full points for criteria 1 and 4, sort of passed the 2nd and failed only in the 3rd criterion, and even that was less severe than I expected it would be.  
The workshop was presented in a fair way - the speaker mentioned that no one will leave this room an expert, and threw some terms around to show that there is more to learn. This is also where I decided that the level of sales promotion was decent - the fact that most of the mentioned "stuff we won't learn today" is taught at the courses was almost unmentioned - Naturally, it was there in the background, but  I appreciated that it was not mentioned bluntly. The only discomfort I felt here was that the speaker did spend some time to convince the audience that it is becoming more and more difficult to find work without "automation skills", and while the market is probably going in that direction, I think there was some cherry picking in the job-ads presented as "evidence" to make it look more significant than it actually is. Still - it felt well within the boundaries  of the game. 

An advantage over the internet was a bit tricky to determine. On one hand, there's someone who knows his way around that can answer questions, explain what is needed and point the way forward. On the other - when one studies alone there isn't this pesky time limitation that forces the approach of "just copy paste this, we don't have time to explain this in detail", and being forced to deal with some technical difficulties usually mean better understanding. It is quite clear to me that in comparison to a good internet tutorial (such as the free parts of Alan Richardson's course), this workshop falls very short: The explanations in the video series are far better than what one could have got in the workshop, and the content is far superior in that that by the end of the workshop the participants had a "main" function that couldn't be used or extended in any way, while following the video tutorial would have left one with a fully functional, albeit very basic, testing project (maven+Junit). However - I knew what to look for. I was familiar enough with Richardson work to suspect he would have a very good tutorial, and I had the knowledge to evaluate the content one I saw it. Simply googling for "selenium for beginners" gave a lot of results that would put the workshop contents in a very good place. So, taking that into consideration, I think there is a small benefit to attending this workshop over trying to learn alone (unless you are reading this post, in which case, you know where to find better content).

Finally, the main pain point is in what I labeled as "respect for the profession". This is the main reason I felt the need to actually attend the workshop: The content of such workshops is pretty much well defined by the genre and will differ only in a few small nuances, but the real difference in in the subtext - in the way things are presented and the subtext of the whole activity. It is important to say that in my eyes every short workshop with the goal of teaching non-programmers to use selenium starts this evaluation with a failing score. A good workshop might flip my impression by focusing on the correct messages, but it isn't trivial to do so.
Here, it actually started with a small bright spot, when the speaker mentioned that in order to learn automation one needs to learn coding, which is an important message to hear when the market is so full with solutions selling "codeless automation". I was also happy to hear that this speaker did not equate automation with selenium (and has provided some reasons for focusing on it first) and that people wanting to know how to automate will have to work hard at it.
However, this wasn't enough. Primarily because actions are stronger than words, and they were sending the opposite message. Automation is not only selenium? then how come that the workshop (and, as far as I understood, the "basic" course as well) is only about selenium? I would have been satisfied with even a single, simple assertion.
Hard work is required to be able to learn automation? How does this align with statements such as "When automating we are not writing 'developers code' " or "A programmer that decides to write automation is probably lacking the skills to write production code"? And how does it align with the whole goal of teaching non-coders to write automation in less than 15 lessons? If I'm generous, that's the amount of time invested in CS101, and no one would dream consider CS101 graduates as decent programmers. In addition, even in a 2 hours workshop, if good coding was something the course provider believes in, I would expect to see some minor tips about naming variables, or extracting logic to function, even if it was only to say "normally I would do this, but here we don't have the time".
If this is the approach taken by course providers, it is no surprise that a candidate thought it is legitimate to claim that they were "an automation engineer, not a programmer".

In conclusion, the situation isn't good.
The speaker is answering a market need - I believe his claims that his students are able to find work in automation. In that he is providing his clients a valuable service. But, I think that this course (and its similar competition) is doing a disservice to both their students and to the profession. The students are getting to the market with a lacking skillset and a skewed perspective about how good automation should look like. Therefore, they are not doing as good a job as they should have been doing. In fact, I would wager that any automation project based on the principles demonstrated in the workshop will fail within three years.
Meanwhile, the market is flooded with low skilled "automators"and the many places that are now venturing into the automation space are finding a lot of bad candidates around - some of them will get hired since the hiring company doesn't know better. In fact, that market learns that "Bad programmers are good enough for automation" and this has an impact in three ways: Good programmers are considering automation to be beneath them, companies paying less those that have automation skills (compare to "real" programmers), and the expectation from an automation project is lowered - making it a self fulfilling prophecy.
In my opinion (which I kept pretty much to myself, as my goal was not to ruin the sales event) any person wanting to learn automation would do well to avoid such courses and focus on learning to code well. If, after doing so, automation will still be a challenge, just take a two hours course on some of the specific tools used in testing. 

Monday, November 12, 2018

אולי אחר כך

Myabe later

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

Timing is everything. Or at least that what's everyone says.
Usually, when said in the context of testing, it has one meaning - getting involved earlier.
Naturally, it is not everything. It is just as important to know when to when not to speak, and even when the opportunity to speak is gone.
A couple of months ago, I was abroad participating in CAST (Was great, thanks for asking). Just before I flew over we finished designing a complicated piece of code in a way that I was quite happy with. Two weeks later when I returned I found out that there were some discussions and the design was changed. I didn't really understand or agree with all of the decisions made, but that's fine - I wasn't there when the discussion was taking place and it's unreasonable to expect them to wait for me just because I took a vacation. As I was catching up, I came across another feature where I had some comments. As I spoke with the team member who was working on this I got a response that went along the lines of "there were countless discussions about it, I'm sick and tired of all this so I just do what I'm told". This raised two alarms in my head: First, we have someone who's writing code they don't agree with its design, which is a source of potential mistakes as writing code is much about having a feel of what part fits where and when you write something you disagree with you don't always have that intuitive understanding. The second, more serious alert was that there were some discussions that went wrong, and we were in the domain of proof by exhaustion, and I don't mean the proper mathematical type of exhaustion. In short, now might not be the best time to ask for a major change I thought was required. Instead, I asked for the urgent changes only (you don't want to go and change database tables once in production, it makes it way more difficult in terms of backwards compatibility) and offered to do the work myself - I went to get agreement from the other people, and changed the code. I also left the important but not urgent discussions for later.
My reasoning for not pressing on this argument was simple: Fixing code is easier than fixing people, and it is much easier to deal with a not so perfect piece of code than to deal with a communication problem in the team.
What I didn't take into consideration was, of course, the human nature: After a while, ideas take root in people's mind and they get used to it, so changing their mind now is more difficult. In addition, changing something in retrospect usually takes more effort than changing it while it is being created, so the price of action is higher. 
At the end, we did have another discussion about the design - I can't say I'm super excited with the result (or rather, with the current result, as the solution is inching its way towards the original design that I liked, only with different terminology), but during the years I've learned one thing - While it's easy to think I'm always right (I am, but this is besides the point) The people I work with know software at least as good as I know it. If someone else prefers a solution I don't like it's usually not because they are wrong, but because each of us gives different weights to the various properties of each solution. What was really important was that we discussed our differences and got to an agreement about how we want to push forward. We also added a task to create a diagram of what we've decided to make sure everyone is aligned - which helped us avoid some mistakes in the future since we found some obstacles earlier.

So, to sum things up - Speaking up is not always the right thing to do - as long as you are having those discussions later.

Sunday, September 9, 2018

Data and Goliath - book review

TL;DR - you need to read this, and I was impressed enough to buy a physical copy of the book.

Listening to Audiobooks is a great way to make use of my time while driving, and it sure makes traffic that much more bearable. As a bonus, I get to learn new stuff. Ain't that great?
This time I was listening to Data and Goliath by Bruce Schneier. I must admit - I wasn't expecting much of it: Big data here, big data there, big data everywhere. In fact, this book makes a very good case for the importance of privacy and does a good job describing the problems in the trends we see in today's economy where data is one of the most valuable currencies. I was eagerly waiting to get to the final section of the book where the author lists some actions we can take to improve the current state of affairs. This last section, sadly, is the one point I didn't like , since after making some promises at the beginning this section can be summed up as "there isn't much you can do, so go ask your government to pass some laws".
After a short summary of the book in the introduction, which is great if you don't have the patience to walk along the details,  the book delivers its content in three section.
The first section, dubbed "The world we're creating" is very much a description of the current state of affaires. It goes over what is data and how it is generated (short answer - we generate data merely by existing, with our phone providing location information, security cameras videotaping us, and everything we do in the internet is, basically, generate data), how surveillance is ubiquitous (a word used many times in this book) and focused on "meta-data", how cheap it is to just pile up the data - we got to the point where storing stuff is cheaper than filtering the interesting bits out. It describes two factors driving forward the momentum of surveillance - the financial incentives of businesses that use the data for marketing that supports a "free" service on the internet, and then sell information as another revenue path. The second is the governments, that quite unsurprisingly wants to know everything - fighting crime and terrorism are the most used reasons to support that. While private companies may collect the data of its users (which might be a staggering amount of data if one considers giants such as Facebook, Google or Microsoft) and maybe buy some data from other companies, but the government is even more encompassing - laws require companies to share that data without much supervision (and sometimes a gag order is issued to ensure everything remains hidden), other regulations might demand a backdoor for use of the government and sometimes the various agencies actively hack products and infrastructure to maintain access to data. One main concept that makes perfect sense and yet I've not considered it explicitly before is that if enough data is collected on the people one interacts with, just about everything can be inferred about a person who, in theory, isn't tracked - just because tracking the others will capture their interactions with that person. The book appropriately uses the term "inverse herd immunity".

The second part is going back to "why?" or, to be more specific, why should we care so much? The most important part, in my eyes, is a head-on challenging of the way too common saying "If you're not doing anything wrong, you don't have anything to hide". This statement is with us way too long, and I've yet to hear a debate around privacy that did not use it in one form or the other. In fact, there are many secrets people keep all the time - Think about people who had AIDS a few years back: everyone who knew that about them would assume that they were homosexual and irresponsible (the former is still not fully accepted everywhere) even if they got infected by a blood transfusion. But that's an extreme case - would you like your employer to know if you've started looking for another place? And what if you were trying to surprise your spouse with a vacation abroad and someone other than you told them that? Would you want a conversation where your manager asked you to help a struggling co-worker become common office knowledge?
We all have secrets. Or at least some data compartmentalization mechanisms in place - we choose which information to share and with whom, and if asked directly, most of us would not volunteer to be monitored (A rather blunt example of the effect of complete lack of privacy can be seen in the the movie "The Circle", which is not a very good movie. You can rather listen to Screen Testing episode 11 which is where I've heard about it).
Besides the personal aspect of privacy, the book mentions other reasons for strongly opposing mass surveillance (yes, we don't usually think of it in those terms, but when just about every company or national or municipal authority has access to data about a large amount of people - this is what it is).
Those reasons are political liberty, commercial fairness, economy and security.
Of those reasons, the one with most aspects is, surprisingly, the political liberty. For starters, let's consider what the author calls a "chilling effect" - when people know they are being watched, they behave differently. Just remember the last time you drove by a police car and slowed down a bit even though you were well below the speed limit. Now imagine driving where you know that by the end of the day, the police would get an exact report of when and where you were speeding, and when and where you were crossing a white line. This can be easily done if the police were to take your location data from your phone or service provider. Such surveillance pushes people to conform with norms
Second is the potential of being harassed by the law - No man is 100% law abiding - people speed, make mistakes on their taxes, cross streets in red light and so on. A strong enough political figure (or a petty enough police person) could make an individual's life a miserable place if they were to dig in on the data about them and look for petty crimes. Mass surveillance helps lower the costs of such activities, and removes most of the regulation around it.
Finally on that matter is the important role dissidents play in social change. It's a bit odd to wrap ones head around it at first, but then it just clicks. Basically, in order to have social change we need to allow for some degree of illegal activities. How so? Consider two rather recent examples: Same sex marriage and smoking marijuana. Looking 30 years back, both of those activities were considered shameful at least, and probably downright illegal (It still is in some countries). Yet, a growing number of people were doing it - first in hiding, then the laws were not enforced and then started the legalisation debate (which is still going on in some places). In the meanwhile, public opinion is shifting. This is possible since homosexuals could hide in the closet and not being persecuted, and since enough people used pot illegally without "getting caught" (or if they did, without serious repercussions) so they could form communities and lobby for that specific activity to become legal and accepted. When surveillance is omnipresent, we get the opposite. The chilling effect mentioned earlier kicks in and people are trying to remain well within the "norm", thus dragging social changes to a halt. When people are aware of being constantly monitored  they prefer to err on the side of safety and not act (in "Think Fast and Slow" Daniel Kahneman states that people value loss or pain about twice as more intensely as gain or pleasure) and thus self-censor their actions and behaviours. This inaction, in turn, is causing stagnation and fortifies the boundaries at what is "acceptable", effectively narrowing them.
The other categories are almost self explanatory -
The economy of a given country is suffering from survelliance since there are other comparable products that will track people less. For a long while the company I worked at blocked Skype from being installed, since Microsoft were (being forced into?) providing a backdoor for the NSA to eavesdrop on Skype calls. After Cambridge Analitica's shenanigans with Facbook blew up, we could see the #DeleteFacebook hashtag running around, and other examples are out there.  The chapter focuses mainly on regulation forcing companies to "share" data with the authorities and asks an important question: if a certain country is known to demand businesses to provide backdoors, and issues all encompassing gag-orders to hide it - who would do business with any company from that country?
Commercial fairness is the term the book uses to describe data driven discrimination. After listening to Weapons of Math Destruction I needed very little convincing that "big data" can be and is being used in ways that discriminate people unjustly. In short, data is being used as a more obfuscated form of redlining (For anyone such as myself lacking the American reference - redlining was a practice where banks avoided investing or approving loans in impoverished neighborhoods). While there is an objective financial gain out of redlining - obfuscated or not - this practice is harmful in the long run, hampering social mobility and punishing people for being poor or part of a minority group.
Lastly is the argument of security. Again, this focuses mainly on activities of governments and other nation authorities. The claim is simple, and widely accepted in the security community: There can be no backdoor that can ensure only "good guys" will access it. By forcing companies to install security flaws to their products, by actively hacking civilian organizations, by hoarding vulnerabilities instead of driving for them to be fixed the governments are making the entire internet less secure.
One last point that is worth mentioning in this section: None of the arguments raised here are new, so one might wonder what has recently changed to warrant such an interest in privacy? The answer is that two things have changed - The first is that storing information has become so cheap that "let's just store that and see later if we can do something with it" is a viable, almost affordable, strategy - so more information about is is being stored. The second thing is that our life revolves more and more around computerized systems. Our phone,and the multitude of security cameras on the street mean that we generate a whole lot of data just by taking a stroll. In the past, information was ephemeral, in that that once a conversation was over, it would reside only in the memory of the participants (recording was possible, but not common). If someone sketched a note and then ripped it to shreds, that information was gone. This is not the case today when we communicate online and our information exists on other people's computers (sometime we call them "servers") that have routine backup, so even data we thought we've deleted might only have been marked in the database as such and not actually deleted, and even if it was deleted, this database might have backup tapes that go years back. Today, the follies we make as teenagers go on social media and will haunt us when we're older - Children will see their parents drunk in photos from 20 years ago, potential employers will see an old tweet they vehemently disagree with, a picture shared by a proud parent today will be used in 20 years to steal that child's identity. The persistance of data ensures that if there's a tiny bit of information we don't want a specific person to know, they are sure to find it.

So, what can we do about it? The book answers this question for three types of actors - governments, corporations and private people. 
The governments wanting to improve the privacy of the world they exist in are quite powerful: They can set rules and regulations that limit the access to data, strive to fix vulnerabilities their intelligence agencies find instead of hoarding them, protect whistleblowers from charges (so that the citizens will know if the government officials are subverting their privacy) and avoid a number of harmful activities exerted by the different departments. The most interesting idea in this part is to provide a "commons" Internet arena - platforms in the internet that are "publicly owned", such as parks or sidewalks - a place where financial pressure to track the users and maximize revenue is negated. Those public domains should be defined with specific laws ensuring proper conduct and resilience to surveillance,  and should be budgeted by the people's taxes.

Corporations, too, are quite powerful in that they are the main collectors of information. So, if a specific corporation decides to collect less data - they can. They can also be very transparent about the data they collect and do a decent job in protecting it so that it will only be used for the purpose it was intended for. Being both technically savvy and large enough, corporations can (and do) also battle the government's attempt to breach security - by creating a secure product when not specifically obligated by law to do otherwise, by challenging warrants and government requirements in the court of law and by investing in research to secure their product. Since the current state of affairs favours businesses that do surveillance it is understandable that quite a large part of the chapter is about "what a government should do to protect from corporations".

The third section is the private people using the internet - being the target of surveillance by two major forces, there is, unsurprisingly very little one can actually do without incurring significant harm to their ability to operate - A person can choose to install some privacy enhancing plug-ins (Privacy badger and AdBlock are two that I use), we can make sure we use TLS everywhere we can, avoid having a social media profile, pay for services that are promising privacy instead of using the "free" equivalents that guzzles your data to increase revenue. One can also leave without their phone regularly, pay only in cash and move to the mountains living off the land. Apart from those rather insignificant actions, the main suggestion is to ask your local politicians to change the laws.

One thing which is important to remember while reading this book is that the idea of trading our privacy for services isn't inherently wrong, and the author does not claim otherwise - processing data, even personal data, can do some good - it can improve people's health and support research (imagine a DNA database that is used to find suitable organ donors, or warn people about dormant life threatening genetic flaws) it can be used to improve road safety and reduce traffic or prevent credit card fraud. Also, minor as it might be, it can help people find things they want by getting better personalized advertisement. The main issue is that the deal today is implicit and all encompassing - there's no backing off from the deal we unknowingly made, and there aren't enough incentives to not keeping all of our data.

The last point I want to touch upon is how fast this book seems to age. It was published in 2015 with what was at the time the most up-to-date information, including some insights from the Snowden leaks in 2013. Despite that, while listening to the book I was having a constant feeling of "missing out". In roughly three years since the book publication, many of the trends shown as warning signs seem to be already in full scale, and reversing the trend seems even more difficult than what is described in the book. I'm a bit optimistic to see some positive changes such as GDPR, and wonder if it will be enough, or will we drift towards a world with zero privacy.

In conclusion - go and read this book.

Also, it just so happens that I finish writing this just before the Jewish new-year, so if you got until here: Happy New Year!
שנה טובה