Wednesday, January 11, 2017

Aedificamus: The Value of Continuous Feedback

One thing I owe my readers is a full review of LoseIt. I keep saying I'm going to do one, but each time I try to get into it, I find the review keeps getting longer and more detailed. For those willing to wait for that, I'll plan to post it by the end of the week. The "tl; dr" version is "a great way to track calories and exercise, interact with others on your journey, and make fitness and weight loss somewhat fun and entertaining, or at least as fun and entertaining as it can be".

The piece I want to talk to for this posting is the community aspect, and how that community can be helpful if you let it be. With a couple of exceptions, my "friends" within the LoseIt app are people I do not know in real life. My sole interaction with them, at least so far, is via the LoseIt app. I know some might think that that's a very weak connection, and probably not really helpful beyond superficial cheerleading. I understand that reasoning, but I would have to soundly say to anyone who thinks that way, "you are wrong".

I had an interesting experience after I came back from Philmont in July 2016. Over the course of two and a half weeks, where I'd exercised a tremendous amount, burned a lot of calories, and kept a meticulous measure of my food, I should have come back leaner and lighter than ever. Instead, I came back close to twelve pounds heavier than when I had left. I was weirded out by that, and I felt a little ashamed. Maybe I hadn't kept as good a track as I intended. Maybe my calculations were wrong. Maybe I didn't work as hard as I thought. Regardless, I certainly didn't want to post a twelve-pound weight gain. What would my friends think?! Yes, even at this point, my primary feeling was of shame because I'd drifted so far off my course. My answer? I'd stop posting my weigh-ins for a bit, jut until I got back to my earlier number and then I could pick up like nothing happened. Surely it wouldn't take that long.

Days stretched into weeks, and weeks stretched into months, and then it dawned on me that I'd stopped weighing in entirely. I still posted, still logged my food, still cheered people on, but my weight hadn't moved on the charts for three months. Hmmm. Well, I better take a look. I mean, come on, how bad could it be?

I stepped on the scale and ended up reading a weight that was thirty pounds heavier than when I reached my lowest weight back in March of 2016. Thirty pounds!!! What the...?!! I knew full well what had happened, and why. I felt embarrassed to post a follow-up. It felt good to get that daily high five for being on track, even if the daily high five was coming from people I didn't really know. For certain, my embarrassment of having to post a reversal made me shy away from weighing in each day, and that shying away from weighing every day removed me from that immediate feedback loop. I ate much the same as I had been, and I figured I was moving about the same amount, but over the course of several months, the food intake crept up, the activity level crept down (injuries and minor aches helped that along, to be fair) and thus, I found myself in negative territory, giving up thirty pounds of gains.

I tried quietly setting a new goal, and I even made a post stating that I was trying a new plan of attack. Net result? New update and a definite highlight of reversal.


What also resulted? One of my friends gently calling me out and reminding me that I'd finally faced the elephant in the room and that I could move forward from here. 

How has reality looked since then? Like this:


That old familiar saw-tooth pattern is with me again. I'm down roughly 6 1/2 pounds in the past couple of weeks. I have up days and down days, sometimes in a row, but usually back and forth. It's maddening, but it's also helpful. If I have a particularly big drop in a day, it's an indication that I can put the brakes on a little. If I bounce up a touch, it's an indication that I need to be more active. If I bounce up a lot, I need to seriously think about what I ate the day before, and see how I make sure to not repeat it today. The key point is everyday feedback, both from my app via pictures and data points, and those daily cheers and well wishes from virtual friends contribute to success. The real takeaway is our online friends are our support system, and they want us to succeed. They will cheer us on, but they will not often call us on our BS. They will wait and watch patiently, to see what we ultimately do. In my case, it was obvious that my lack of weigh-ins was a sign that I'd lapsed. When I stepped up and admitted it, no one called me a failure or lazy or any of that. They just said "glad to see you are back on track. Good luck out there."

Fitness goals are often challenging. They take a lot of patience and focus. Quick feedback is helpful but more important is a willingness to accept that feedback and actually act on it. Get over the embarrassment of lapsing. It doesn't mean we lack discipline. It means we're human, like roughly eight billion others out there. Own that humanity, log the discrepancies and move on. Our friends want to celebrate our successes, not remind us of our failings. No, really, it's true. If we have a bad day, acknowledge it, deal with it, and do better the next day, and the next day, and the next. Ultimately, we will reach the goal we have set and probably much faster because we are allowing for regular feedback each day. Don't let temporary embarrassment derail your goals. Use the feedback each day to plan an even better tomorrow.

Tuesday, January 3, 2017

Everything Old is New Again: Adventures in Khan Academy

One of the things I decided I wanted to do more of back in December (remember, I don't do New Year's Resolutions, I try to ingrain habits before January 1st whenever possible ;) ) was to look back at the areas of my knowledge that I once knew or learned, but that time and inattention have seriously atrophied. For me, one of those areas is Mathematics.

Granted, I use programs, spreadsheets, and calculators quite a bit. I can manipulate formulas and compare results as good as anyone, but how well do I really remember even the most rudimentary of skills? How do I find the area of a trapezoid? Can I do Greatest Common Factors and Least Common Multiples quickly in my head? How much Geometry do I really remember? How about Calculus? OK, to be fair, I made it through first-semester Calculus in college and was overjoyed to have received a good grade. I then stopped due to time and work constraints, so I only got so far.

Khan Academy has what I consider to be a neat collection of Mathematics courses and challenges that you can work through. They have Mathematics topics broken down by discipline, as well as by what grade (K-8 and High School) they represent. At the moment, I'm reviewing 6th Grade math (hey, you have to start somewhere, right ;)?). They have individual modules that you can practice, videos that talk about the concepts, and mastery challenges you can perform and record your progress. My current goal, alongside keeping up a streak as long as I can, is to get to 100% mastery on all math levels through high school. As you can see, I have plenty to do still:


As a kid, I used to consider Math to be the bane of my existence. Now? It's fun! What's more, I'm realizing how many things I learned one way, but are now being taught in a slightly different manner. It's been fun to see the differences and how some of the explanations are better than what I learned, and how I still reactively use the tools I was given several decades ago because, well, that's what I mastered and still consider "my way" of doing it. Perhaps more interesting is looking back and realizing that I either learned many of these things much later than the grade they correspond with or that I never learned them at all, at least not in this context.

Khan Academy does a great job at focusing on the basics, and I'd like to challenge my readers out there to pick an area they'd like to develop a better proficiency. Like me, you may discover that you'll be eating a few pieces of humble pie along the way, but you may also unlock a fun new pastime looking at something you may have long since stopped using, or at least actively thinking about.

If you'd like to follow along with me, my Khan profile is here :).






Tuesday, December 20, 2016

Water Flowing Underground



Well, it's the end of another eventful year. Much has happened. I've been involved in many interesting endeavors, and I've learned a lot about myself this year. This was a topsy-turvy year for many, both in the pop culture and political sense. It seems for many we are making decisions to look for ideas and think about things in ways that agree with our views of the world. That's both rational and long term bad for us. I won't be talking about politics with this post, other than to say that I believe local action and local involvement has to be where we all start because that's where we individually have the most control and effect.

The title this year of this post is "Water Flowing Underground", and yes, this is yet again a lyrical nod to the Talking Heads song "Once in a Lifetime". Why did I choose this line for 2016? It felt like this was a year of digging. If I wanted to get to the water that would sustain me, I would have to work for it, and in many cases, work harder than I have before.

First, let's start with a little bit of "Aedificamus". This was a year I focused on being more quantified in my actions. I measured my food. I measured my exercise. I wore a fitness tracker each day. I set a goal and I came darn close to achieving it, and then part of me stopped paying attention. No, that's not really true. The truth is I grew weary of the level of activity and focus needed to hit the aggressive goal I had set for myself. What's more, I discovered that I was capable of being injured in ways that took far longer to be healed than I imagined possible. I developed golfer's elbow (which is odd because I don't play golf). Seriously, though, what that means is that I developed a repetitive stress injury on the inside of my elbow, at the joint where my humerus and ulna meet. It's made lifting weights and doing a number of exercises challenging. I have to be careful as to how I lift things and how I use my elbow. In addition, in the latter part of the year, I developed plantar fasciitis in my left foot. What that has meant is that my previous gung-ho approach to walking 10,000 plus steps each day is now determined by how my foot feels in any given day. The net result is that I gave up some of my progress on my weight loss. I'm still considerably less than I was at the start of this journey, but compared to this time last year, I'm actually up about ten pounds. Still, I am wearing the clothes I bought for the smaller framed me, and they still fit comfortably, but I have a reminder that I need to mend and I need to keep healthy, plus I need to figure out some adaptations to my training and eating so I can get back to making progress, even when my body doesn't want to cooperate.

Next, I made a conscious decision to scale back on several areas so that I could focus on a few key areas I've really wanted to develop. That meant taking a step back from freelance writing and yes, even contributing to this blog, so that I could help bring forth a new venture. That new venture that started this year is "The Testing Show", a podcast that I produce, edit, transcribe and publish each week through QualiTest and on iTunes. I knew going into this that I had a goal for the production quality and listening experience for this podcast. To that end, I think it's safe to say that I've spent more cumulative time on this show than any other initiative I've been involved with this year. As well as being a regular panelist on the show (along with Perze Ababa, Jess Ingrassellino, Matt Heusser and Justin Rohrman), I also edit every show and produce a transcript and show notes for each episode. In short, if you like the flow of the show, the accuracy of the transcript and the relevancy of the show notes, I get to take the credit for that. If you don't like them or find any of the above in need of improvement, I am also the one to talk to about that. Without going into details, I probably spend anywhere from six to eight hours producing each episode. That's because I want the listening experience to be clean, and I want the transcript to be as accurate as possible. Do I have to edit the shows so that every "um", "ah", "like", "you know", and circular verbal tic is removed? Probably not, but I value podcasts that go that distance. Shows like Freakonomics, Planet Money, and Hardcore History are my gold standards. I aspire to have our shows be that clean and that focused. Sometimes I succeed, sometimes I miss the mark. Each time I learn something new and get just a little bit better.

On an additional physical level, I took on what was possibly the biggest trek of my life, as well as the biggest challenge to the way I live and work every day by going off the grid and hiking into the New Mexico wilderness in July of this year. As Scoutmaster of a Boy Scout Troop, we put together an expedition to spend sixteen days in the Southwest, twelve of them at Philmont Scout Ranch and the surrounding Carson National Forest. We hiked for ten days, covered about eighty miles on foot, climbed over a few mountain ridges, dealt with extremes of temperature, and learned how to orienteer for real in spaces where there were no trails. Most of all, I had to make the decision to turn leadership over to a group of 14-16-year-olds and put my trust and faith in them that they would make the right decisions for the ten days we were on the trek. I am very much of the mind that I often do things myself if I don't trust that they will be done the "right way". Well, the Philmont Way doesn't care what the adult leaders think outside of an advisory capacity. What the boys decide determines the outcome, and we agreed to that. Most of the time, it turned out OK. Occasionally, I had to be sneaky and offer suggestions or show where we needed to go, but I was admonished by my co-leader that I needed to keep such interventions to a minimum. We all made it through intact, some scrapes, some bruises, a little altitude sickness here and there, but overall, much better for the experience. What's more, I learned that I had it in me to hand over control to others, and I learned to accept that my way need not be the only way. It about drove me crazy at times, but I was happy for the experience nonetheless :).

On the conference side this year, I decided to focus on my own area this year. Philmont was going to take a lot of time this year, so I decided that I would not travel for conferences this year. I was happy that STPCon came to Millbrae, CA, and I was also happy that the organizers told me, in no uncertain terms, that I had BETTER submit some talk proposals, as they were literally less than five miles from my home. To that end, I presented talks on the Intersection of Accessibility and Inclusive Design and shared a workshop on How to Teach New Testers. Those topics were also worked on and developed more in the Bay Area Software Testers meetup, along with our quarterly Lean Beer discussions, which opened up new areas for me to dig this year.

On my everyday work side, we've been making changes to our core team. Some of our most seasoned veterans have moved on to other endeavors. I've celebrated four years at Socialtext, and I am now the fifth most senior person in our company. That seniority is measured in weeks and months in a few of those cases. This means my leaning on more knowledgeable people gave way to my having to dig even more and learn even more than I ever thought possible. I now feel like the one that people come to for answers, both in the testing sphere and, more frequently, in the programming sphere. While I can safely say I have a lot more to learn in that latter area, I do feel that I am working in an environment that will let me dig as deep as I want to with as much energy as I can muster, and I will be encouraged and helped along the way. That's one benefit of working for what is, in effect, a very small company, even though that company is an acquisition of a much larger one. We are left to run as a scrappy little team, and that scrappy little team encourages everyone to dig if they want to.

So what does 2017 look like? I'm hoping to get back out and participate in conferences again, whether it be as a participant or as a speaker. I'd like to attend some development conferences or some broader industry events, and see if I can help develop a broader message of testing and quality. I'm aiming to expand Weekend Testing Americas to do more events at different times other than just on Saturdays (that's what people have said they want to see, so we will certainly give it a try). All in all, I am optimistic, and if there are areas that I am less optimistic about, I am going to remind myself that if it is within my sphere of influence and control, I best do all I can to influence events and outcomes as much as I can so that I can be optimistic going forward. One thing is for sure, water's flowing underground. If I want to get to it, it's up to me to dig for it. Same as it ever was ;).

Friday, November 4, 2016

Adventures in Empathy - Simulating mild vision loss with the Cambridge Inclusive Design Toolkit

Last year, I spent a fair amount of my presentation time talking about ideas behind Inclusive Design, and how the both enhance and help contribute to performing Accessibility testing. One of the resources I suggested was the Inclusive Design Toolkit developed and used by the University of Cambridge. In addition to a wealth of information on their site, their methods go beyond software. Since they test numerous physical items, they do not rely on software tools only but have actual physical tools that you can use.

One of those is their Cambridge Simulator Gloves. These are rigid pieces of flexible plastic that can be adjusted to simulate a variety of physical issues with hands (e.g. rheumatism, arthritis). These are seriously cool pieces of kit, but they are pricey (£155 per pair, which is at this writing close to $200). Less expensive but also seriously cool are the Cambridge Simulation Glasses. These are considerably less expensive (£30 for a set of five glasses, which is less than $40 as of this writing), and therefore are easier for individuals looking to dabble in Inclusive Design to do so. The University of Cambridge is quick with orders and I received mine within a week of placing it. For shipments coming from the UK to the USA, really, that's pretty good.

Here's the single user Cambridge Simulation Glasses pack.


OK,  so what in the world is this?

The idea behind the simulation glasses is that you as an individual can experience progressive vision loss. Personally, I can already empathize because I have developed classic middle-aged person near-sightedness; I need readers to type this blog post, for example:
Not a fashion accessory, but also not a permanent fixture on my face (yet).
I do need them anytime I try to read or type anything.

If you are not already wearing prescription glasses, contacts, or need readers just yet, you may be wondering how you might be able to simulate mild vision loss. The simulation glasses do exactly that. Just put a pair on, and you will experience a little bit of fuzziness to your vision. If you want to intensify the effect, put on another pair of glasses over the top of the ones you are currently wearing. The kit comes with five pairs of glasses, and believe me, by the time you have put on all five, you will find it challenging trying to read much of anything.


If you wear glasses, you wear these over the tops of the ones you are wearing to give you a graduated simulation.

The loss of visual quality as you stack glasses.

The image above gives you an idea as to how fuzzy your vision gets with these, but it is even more jarring as you actually wear them. aAt the maximum level, you can really see how frustrating it is when you try to look at a screen or an object that has low contrast. Trying to determine what it is, much less how to use it, can be a real struggle. Again, there are software tools that simulate this, but there's something very interesting about being able to put on these graduated "fuzz" devices and try to do everyday tasks I take for granted.

For those who are interested in experiencing your apps, or your everyday products in a new way, and to develop a bit of empathy for your less visually normative friends (and those who live long enough will most likely get to join our ranks), then I do encourage getting these simulation glasses. They are worth the expense, and they do help reshape and reframe the way you see the world... or don't see it, in this case.


Thursday, October 27, 2016

Adventures in Tautology - What Makes a Tester a Tester?

The latest The Testing Show has been released. Some interesting thoughts and comments have been spinning through my head since we recorded this episode. For a number of organizations, the "tester" as we have long identified them, is going away. In this sense, I mean the dedicated person who focuses on testing as a specific discipline, who gets into the guts of an application, who spends the bulk of their time actually testing the product, independent of any other responsibility. For other organizations, testers are a huge part of their infrastructure, as essential and as non-replaceable as a plumber or an electrician. Why is there a disconnect? Is there a disconnect?

First, a little about my history. I can safely say I have worked for three companies that specifically needed to have dedicated testers. That's not to say the others didn't benefit from having testers, but I'm talking about how they were physically structured, staffed and what they made. Cisco was my first experience in the world of software development, but also hardware development and maintenance. That's where I saw first hand the different definitions of what a tester was.

First, there was the tester on the Engineering side of the house, those of us who worked on IOS (Internet Operating System, not to be confused with the much later appearing iOS from Apple), and on the microcode that resided on system boards. These teams had dedicated testers who spent a lot of time working with early automation frameworks or even just running commands via 'tip' to get access to the consoles of these devices to work with them. We also had quite a few of us who were involved with physically building up test labs, configuring the hardware, bringing in diagnostic tools and doing wide-ranging experiments. In short, we did things that the developers just plain did not have the time to do, at a level that provided a lot of feedback to further development and design, as well as to hunt down problems.

Aside from that, there was also the Manufacturing side of testing, which was a very different animal. For the first nine months that I worked with Cisco as a contractor, I was dotted-line associated with both Engineering and Manufacturing, and I sat in on meetings with both groups. It was here that I really saw the difference. Manufacturing testers were often times better described as "rework specialists", in that they tested, but they also rerouted and resoldered boards so that they could be re-deployed. I confess, I often felt out of my league with this group. It seemed they knew so much more about the bare metal issues than I ever could, and they also knew quality issues they had to address within seconds of looking at a particular board. I still smile when I think of going to talk to my friends Winnie, Jim or Azhar, among several others, and just their quick ability to look at something and say "oh, yeah, I can tell you what's up with that!" This was a skill, a craft, that I would say, honestly, only a handful of the software engineers possessed. This was a knack that was inspiring. I would ultimately work on the Engineering side of the company, and I would often suggest that, if we really wanted to augment our test teams, we really needed these people over in manufacturing to join us. Ultimately, several of them did, and yes, our test teams immensely benefitted from them being there.

The other two companies that required testers were Synaptics and Konami, for different reasons. Synaptics definitely because it was a blending of the software and the hardware (and truth be told, I think I found more issues with product tensile strength or composite construction than I did with software). Konami because of the factors that are so subjective when it comes to gameplay outside of "correct programming" (and the all important "physics tests", which, frankly, I don't wish on anybody). Oh, and in my case, they wanted to release a singing game, so they needed someone who could test and sing really well. Truly one of the most serendipitous jobs of my life :).

All of the other companies that I have worked for, I'd be hard pressed to say we essentially "required" dedicated testers, but again, I think we were well served to have them. Over time, though, as systems moved on to regular builds, incremental development and design, smaller and more frequent releases, and quicker answering to customer feedback, I can see why it would be easy to say "testing is a role and not a full-time profession, and we can do the testing with a smaller team or, even, with a single person" (which many times was me). Often, my testing role would be used, but I would be asked to do other things as well, such as provide second tier support, perform training, work on automation frameworks or, often, just look at the maintenance tasks within an organization. Side note, if you have not heard the Freakonomics episode about "In Praise of Maintenance", may I suggest you do so, as it has excellent commentary that is quite relevant to this discussion.

Since I've left Cisco, I have, generally, worked for smaller organizations. Those organizations have, at times, been subsidiaries to bigger companies, but usually, the group I work with is the entity that I interact with, so for all practical purposes, they are my company. That means I typically work with teams of around a dozen developers, rarely more, and most of the time, I've worked with me as a lone tester or, maybe, with one or two more testers. Most of the time, we are not just testers doing just testing. We cover a variety of other jobs and needs, and frankly, in smaller companies, that's to be expected. It's not uncommon for a tester to also become a de-facto systems administrator, or a triage support person, or a build master. We still test, of course, but also we encourage others to test as well. I'd say it's not so much that testers are going away, but that the role of testing is being seen as necessary in many places and not encompassed by a single person.

Ultimately, what we come to is that Testing as a discipline and as a craft is an essential part of software development. I still hold to the truism that training in testing discipline and philosophy is valuable, and those who do so will be uniquely positioned to benefit from doing that. I'm also saying "don't be surprised if you find that your job responsibilities are not just testing, or that you may even find you are not ultimately called a tester at the end of the day". At this point in time, my job title as defined by HR is "Senior Quality Assurance Engineer". Time agrees with the Senior part. Having to finagle and discover workarounds begrudgingly lets me consider myself an Engineer (I've never really been comfortable with that title because it means something specific in other industries that I have no chance of meeting requirements for), but Quality Assurance is my bag, even if the words are a little tortured. In short, I work in ways that help to encourage quality. I'm on board with that. I'm also on board with the fact that I often bring many other skills to the table that organizations can use, and that those skills can be leveraged to provide value for my company. Many of those skills have been informed by testing, but are not in and of themselves "testing".

To come back to the beginning, I think all of us test and all of us are testers, but there is a benefit to having a group who pays attention to the testing discipline more directly than others might. I'm happy to be part of that group, but I also understand that that alone will not make me valuable to an organization. Being a good tester is important, but if the desire is to work for smaller companies, do not be surprised if you are asked, "what else have you got?"

Thursday, October 13, 2016

Start Making Sense with Sensemaking - a #TheTestingShow Follow-up

One of the primary reasons that my blog is not as frequently updated as in the past is that I have been putting time into producing The Testing Show. Granted, I could do a quick edit, post the audio and be done with it, but we as a team made the decision we wanted to aim for a show that would flow well, be on point, and also have a transcript of the conversation. At first, I farmed out the transcripts, but I realized that there was a fair amount of industry specific stuff we would talk about that I would have to go back and correct or update, and then I'd have to put together the show notes as well, with references and markers. realizing this, I decided it made sense to just focus on the transcript while I was making the audio edits, so I do that as well.

Translation: I spend a lot of time writing transcripts and that cuts into my blogging. My goal is to make sure that The Testing Show is as complete as possible, as on point as possible, and that the words you hear and read are coherent and stand up to repeated listenings. Also, since it's a primary activity that I do within our little testing community, I really need to do a better job highlighting it, so that's what this post is meant to do. Consider it a little shameless self-promotion with a couple of additional production insights, if you will ;).

Occasionally, I get a podcast that tests my abilities more than others, and this week's episode proved to be one of those. We try our best to get the best audio files we can, but sometimes, due to recording live at a conference, or trying to capture a Trans-Atlantic call, we have to deal with audio that is not crystal clear. Often we get background noise that can't be isolated, at least not effectively. We sometimes get audio that is varying levels between speakers (one is loud, the other is soft, and leveling means introducing line noise to compensate for the low volume of a speaker). This time, it was the fact that the audio stream would just drop out mid-sentence, and we'd either have to repeat several times, or we'd lose words at random places. Because of that, this is a more compact show than normal, and that was by necessity. It was also a challenge to put together a transcript; I had to listen several times to make sure I was hearing what I thought I was hearing, and frankly, in some spots, I may still have gotten it wrong.

With that, I want to say that this was an interesting re-framing of the testing challenge. Dave Snowden is a philosopher, writer, and principal creator of the Cynefin Framework. "Cynefin" is a Welsh word that means "haunt" or "abode". In other words, it's the idea that there are things that surround you all the time that can give you clues as to what's going on, but you won't notice it unless you "live in it". There's a lot more to the framework than that, and Dave Snowden talks quite a bit about what it is and how it's been applied to various disciplines. Anna Royzman also joined in on the call and discussed her involvement in using Cynefin, and what it might mean for software testers who want to use the framework and approach with their testing. A caveat. This is a framework that has been used in a variety of places, from applications in government to immigration to counter-intelligence and software development. Testing is a new frontier, so to speak, so much of this is still to be determined and very much in the "alpha" stage.  Anyway, if you'd like to know more, please go have a listen.

Sunday, October 9, 2016

The Humans In the Machine - Talking Machine Learning

This weekend was one of the more interesting Weekend Testing Americas sessions I've hosted. Hurricane Matthew was making itself known and people were dealing with getting in and out of a broad section of the Southeastern United States on Saturday, as well as looking at whether or not their homes were OK. Under those circumstances, I can understand getting together to talk testing may not have been a high priority. We had several people ask to attend, but by the time it started, there were just two of us, Anna Royzman and myself. Anna and I both decided "hey, we're here, Anna's never done a Weekend Testing session before, let's make the most of it" and so we did :).

Our topic this go around was a chance to look at a new feature of LoseIt called SnapIt. The purpose of SnapIt is to take pictures of food items, and based on what the app thinks the picture is, select the food item in question and get a macronutrient breakdown. This is a new feature, so I anticipated that there may well be some gaps in the database, or that we might get some interesting tags to appear. We were not disappointed. In many of the pictures, well known food items were easy to identify (apples, bananas, etc.) and some a little less so (a small pear variety that had a darkish green skin was flagged as Guacamole, which isn't really too far of a stretch, since I could see it interpreting it as a small avocado):





Complex and packaged foods it struggled a little more with, but in those cases, if it has a bar code, most of the time, reading the bar code would deliver the information we needed, so SnapIt was less important in that setting, but it was interesting to see what it flagged things like granola bars or shelled walnuts as.





During the session, we did discover one interesting bug. On my iPhone, if a user takes two pictures, and discards them, and tries to take a third picture, the camera button on the screen appears as a half circle. The bottom of the button is missing. Exit the camera and open it again, and the camera button appears complete again. Shoot two pictures and throw out the two, you will get the half button on the third try.



Outside of the actual testing of SnapIt, we had a pretty good discussion of machine learning in general and the idea that many of the algorithms used for these processes are pretty good, but can often have unintended consequences. The past few weeks, I've been listening to a number of podcasts that have featured Carina C. Zona and her talk "Consequences of an Insightful Algorithm" (talk and slides). She has appeared on both the Code Newbie podcast and the Ruby Rogues podcast, and both treatments made me want to explore this topic further. One comment from Carina's presentation that stood out to me is the idea that "math (algorithms) are objective conceptually, but their implementation hardly ever is, because it's people who create them, and we create algorithms with our prejudices, biases and fallacies intact. In short, we do not see our algorithms for that they are, we see them for who we are (paraphrase of Anais Nin, but you get the point, I hope ;) ).

I'd encourage anyone who wants to get a better understanding of the potential dangers of relying too heavily on machine learning, as well as the human aspects that we need to bring to both coding and testing those algorithms, please check out Carina's talk. For those who want to see some of the terrain that Anna and I riffed on, please feel free to read the chat transcript of the WTA session.

Friday, October 7, 2016

In That Moment of Terror, Evolution Occurs

There has been much of interest in my day job as of late. Much to keep me busy, much to ponder and consider, and definitely wondering "where do we go from here?"

In the course of the past two weeks, we've received the news of two, frankly, heavy departures from my company. One of them is for an amazing reason. Our senior software developer, Audrey Tang, has left us to become a Minister without Portfolio in the Executive Yuan of the Republic of Taiwan. Seriously, how does a software company compete with that? The second is of our Vice President of Engineering, who has been with our company for ten years, and has the deepest institutional knowledge of anyone in our company. With these two departures, I've come to realize that I am now one of a small few who are the senior members of the team. In short, whether my role or job title reflects it, I'm now one of the "sages" of my company. Only four other people have longer tenure, and that's measured by months, not years.

To be honest, some people are fearful. What does this mean? Where do we go? Can we do what's expected? Those are completely legitimate questions, and I find it interesting that a number of people are asking me for my "lay of the land" in this situation. I'm not going to talk "out of class" so to speak, but I am going to share some general thoughts that I think are relevant to anyone in any work capacity, and they match my general philosophy overall.

This is a time of uncertainty, sure. How long will it take for us to replace these two people? I'll argue that they can't be "replaced". We can hire people, or promote people, to fill their roles, but we will never "replace" their drive, genius or quirks that made them effective. My answer is "don't try". No, I don't mean give up, I mean don't try to replace them. Instead, forge ahead with new personalities, new ideas, new modes of genius, and dare I say it, insert yourself into the conversation or situation if it makes sense. First, who's going to stop you, and second, they probably are elated you want to help carry the load.

Evolution doesn't come at times of health, well-being, peace and comfort. It comes at times when there is a crisis, or a threat of extinction. We don't learn when things are going well, we learn when things are going haywire, and we need to solve real problems. Over the past few years, I've determined the best course of action is "We seem to be having some trouble here. How can I help?" I came into my current company as a tester, with testing my sole focus. Upon the death of a co-worker and mentor, I took over their role as Release Manager, and became more familiar with our code base than I likely would have otherwise. I didn't get promoted into that position. I saw there was a hole now, and no one there to do that job, so I decided to figure out how to do it. No one said "No, you can't do that, you have to go through channels". Well, not entirely true, I did have to convince a few people I really did learn enough about what needed to be done to get access to resources necessary, and in that process, I did basically declare "I'm Socialtext's Release Manager", when there was no one official to back me up. What happened? The de-facto became official. I became Release Manager because I declared I would be it, and under the circumstances, there was no one in a position to really object.

Today, I see similar opportunities. If I ever wanted to declare myself as the head of Dev-Ops, or to declare that I am now a supporting software developer, or even help chart architecture decisions, that time is now. However, I will not be able to really do that unless I am also willing to put the time in necessary to show I have both skills and willingness to do it. I'll not pretend that I'll be promoted to VP of Engineering. That's a bit beyond my skill set or desire, and we've already got a new VP of Engineering, but they will feel like a fish out of water for awhile. My plan is to do what I've found to be most helpful, which is to say "you seem to be struggling with some challenges... how can I help?"

Thursday, September 1, 2016

This Week on #TheTestingShow: Real Work vs Bureaucratic Silliness

I have come to realize that I am terrible in the shameless self promotion department. I have been actively involved the past several months with producing and packaging "The Testing Show", but I've not been very good about talking about it here. Usually, I feel like I'm repeating myself, or I'm rehashing what I already talked about on the episode in question.

When Matt takes the show on the road, however, I do not have that same issue. This most recent episode of The Testing Show, titled "Real Work vs. Bureaucratic Silliness" was recorded at Agile 2016 in Atlanta. As such, Matt was the only regular panelist there, but he put together a group consisting of Emma Armstrong, Dan Ashby, Claire Moss and Tim Ottinger. For starters, this episode has the best title of any podcast we've yet produced for The Testing Show (wish I came up with it, but it's Tim's title). I think it's safe to say all of us have our share of stuff we like to do, or at least the work that is challenging and fulfilling enough that we look forward to doing it. We also all have our share of "busywork" that is inflicted on us for reasons we can't quite comprehend. Tim puts these two forces on a continuum with, you guessed it, Real Work on one side, and Bureaucratic Silliness on the other.

I think there's an additional distinction that needs to be included in here, and that's when to recognize that some task, behavior, or check point actually is an occupational necessity, and when it is truly Bureaucratic Silliness (BS). In my everyday world, let's just say this tends to grade on a curve. Most of the time, BS comes about because of a legitimate issue at one point in time. Case in point; some years ago, in spite of an extensive automation suite and a robust Continuous Integration and active deploy policy, we noticed some odd things passing through and showing up as bugs. many of these things were not areas we had anticipated, and some of them just plain required a human being to look them over. Thus, we developed a release burn down, which is fairly open ended, has a few comments of areas we should consider looking at, but doesn't go into huge details as to what to specifically do. The burn down is non negotiable, we do it each release, but what we cover is flexible. We realized some time back that it didn't make sense to check certain areas over and over again, especially if no disruption had occurred around those features. If we have automated tests that already exercise those areas, then that likewise makes it a candidate to not have to be eyeballed every time. If a feature touches a lot of areas, or we have done a wholesale update of key libraries, then yes, the burn down becomes more extensive and eyeballing certain areas is more important, but not every release every single time.

Usually, when BS creeps into the system, it's because of fear. Fear of being caught in a compromising situation again. Fear of being yelled at. Fear of messing something up. We cover our butts. It's natural. Once or twice, or until the area settles down or we figure out the parameters of possible issues, makes sense, but when we forget to revisit what we are doing, and certain tasks just become enshrined, then we miss out on truly interesting areas, while we go through BS to the point that we would rather pull our intestines out with a fork rather than have to spend one more minute doing this particular task (yes, that's a Weird Al Yankovic reference ;) ).

Anyway, were I part of the panel, that's part of what I might have brought up for discussion? If you want to hear what the group actually talked about, well, stop reading here and listen to The Testing Show :).

Friday, July 29, 2016

Consider the Source: A Tester Invades Philmont

One of the more entertaining aspects of our trek would have to be the final two days, in that we were joined by an expedition mate that, let's just say, is a little different than the average hiker:


Testhead readers... meet "T.K."

Actually, his real name is "30", which is the number he wears around his neck for identification purposes,  but part of the "Burro Expedition" experience is that each crew gets a burro to join them for two days, and the crew gets to name the burro for the duration of the trek. Needless to say, it would be impossible to keep track of the names changing all the time, so the burros are officially known by their numbers, but are also conditioned to respond to any name they get called. 

During our trek, the boys talked a lot about the Anime series "Angel Beats" (which also happens to be one of my favorites), and we joked a lot about who our favorite character in the series was. That character was "T.K.", a long haired, always moving dancer who would speak in nonsensical English phrases (even in the original Japanese recording). When we met burro number 30, and he came up to us and looked at us with a circular head bob, we all laughed at the similarity to the movement T.K. did in the anime, and we all said "Hey, let's call him T.K.!" With that, T.K. became an official member of the crew, and would help us on the trek for the last twenty miles or so by carrying some of our gear for us.

As we were making our way to the Baldy Skyline camp area, we had a number of choices we could take to get there. As we scanned the area, we saw that there was a road that looked to be a straight shot up to the area, and pretty short by comparison. We started walking towards the camp and for the first bit of the stretch, T.K was walking alongside us and made no fuss. When we saw a fork in the road, and the trail that continued up to the camp area came into view, TK started walking that way, but we guided him back to the main road. Over the course of the next few minutes, TK walked slower and slower, and finally stopped. We tried to coax him forward, and we'd get a few steps in, and then he'd stop again. We did this about half a dozen times, and each time, it was getting to be progressively harder to move TK further up the road.  

Additionally, as we looked at T.K., we had the impression he was looking at us as if to say "hey, you guys are all idiots! Did you see that trail that forked off the main road a while back? That's where we're supposed to go. Trust me, I've done this trek more than a few times, I know how to get there!" Still, we felt confident that our short cut would work and save us time, so we persevered. I've had experience leading horses and burros in the past, so I took it upon myself to hold his bridle and lead rope and coax him up the road, and ultimately, he let me lead him up the road.

The road we had chosen changed. It became steep. It was straight, sure, but it was also a laborious climb to get up to the ridge line where the camp was. It was tiring, it was in direct sunlight, and by the time we reached the top of the road and the ridge line, we realized that, while we were at the top of the hill, the actual camp area we needed to be at was still about two kilometers east. As we trudged to the camp area, we saw the trail converse with the upper road, and we also saw that the trail was coming out of a wooded area, with plenty of shade, the trail meandering through a range of switchbacks that, while longer in total distance, would have been much kinder to our knees and backs. As I looked at T.K., it felt as though he was saying "See, I told you you were an idiot! I could have led you here and saved you a lot of hassle, but no, you had to go your own way. How did that work out for you?"

Does this sound familiar? I know it does to me. I've had this experience with my teams. We are so sure that what we are going to do will save us time, it will be different than all the previous times we've tried to meet a goal, but someone, usually one with a lot of experience, puts up resistance and tries to point out what we should be doing. Often, that advice goes unheeded, only to come back and bite us later when we realize that the insight was valid, accurate, and based in experience, but our hopes and optimism for a faster way (or a looming deadline) blinds us to the hard earned experience. 

I chuckled as I thought about this the following day, when we left the Baldy Skyline camp to head down to the next area and followed the main trail. T.K. just started going, and he barely stopped. He knew where he was, and he knew where we needed to go. Sure, we consulted our maps to be sure, but otherwise, the trail was the most direct route, and he just plowed ahead until we chose to call a halt for a rest break. During the remainder of the trek, as we were debating ways we should go, I'd quietly nudge T.K. to move forward, and I'd see where he wanted to go. Typically, I'd encourage following his lead, and each time, it would prove to be the most direct and easy to navigate route. Sure, it would have been more adventurous to bushwhack, but I'm sure T.K. appreciated not having to climb over or around felled trees or other obstacles.

There are times when new vistas are open to you, and there is no trail to follow, and one way is as good as any other. At times, though, there are those who have gone before us, and instinctively know when we are going the wrong way. It's wise to step back and listen to those who express reservations. Who know how much sweat and toil they might save us if we listen to them ;).