Doing the Unstuck

Recently, I came to a conclusion that was unavoidable. I was paralyzed by too many things, too many commitments, and too many good intentions that I just couldn’t get any traction on. I am frequently the victim of “analysis paralysis” because so many things end up getting clogged and feel like they are impossible to make any real movement. This makes me feel more frustrated, and instead of making forward progress, I actually slip back and get even more mired. In short, I get stuck in my own psychic mud.

I find it most aggravating when I know someone else is waiting on something from me. What often happens is, I know we have something I need to do, I know I want to get it done, but I don’t really have the time to get it done, or so I think. What happens? I psychologically start distancing myself from that person or group, I start avoiding what I need to do, and thus I get farther and farther behind, and the vicious cycle continues.

Ah, but I’m not here to talk about the vicious cycle, I’m here to talk about breaking it. For me, the easiest way to do it is to include the person or group in the very thing I am stuck in and make sure they are part of the conversation. For me, recently, Skype has proven to be my best piece of “psychic WD-40”. How so? Instead of sitting around waiting for a problem to fester, I instead use Skype to reach out to the person or group that’s not getting the attention, ask them to work with me to set a time (or better yet, right then and there, if they can) and help me get unstuck.

For many people, this is a really hard step. Why? It means we have to admit that we are wrong, or that we are lacking in self-management or time-management skills, or some other deficiency that we have not been able to resolve. It means we have to admit to our fallible humanity. To all of that, my best recommendation is to say to yourself and everyone else… so what? I’m human, I’m fallible, I make mistakes, and occasionally, I bite off more than I can chew. Sometimes it comes down to realizing we don’t know something we think we should, and we will expose ourselves as being foolish or stupid. Well, guess what? We all are ignorant, foolish or stupid at some point.

Freely admitting it, and getting help from those who we are supposed to be doing something for is the best way to break that log jam. It has two major effects. First, it allows you to focus on the issue, and second, it allows the person or group who you are doing the service for to help make sure you are working with the correct information or understanding to be successful. Ultimately, people don’t care if you get it right the first time, as long as you get it right in a reasonable time frame and help solve the mutual problem.

So if you find yourself on the hook for something, and you feel stuck in trying to deliver it, stop… breathe, and then get on Skype, or chat, or pick up the phone, or whatever immediate tool is at your disposal (key word here is "immediate"), and work with that person to get unstuck. Sure, your pride will take a little beating, but seriously, would you rather be proud, or would you rather be done?

Hairballistics: An #AU4H and #WeekendTesting Introspection

We're back again at Agile Up 4 Here, and we were furiously getting things ready for presentation at what would be Weekend Testing Americas session #28. For those who didn't see my post yesterday, Agile Up 4 Here (#AU4H) is a code retreat that goes for one week. Elisabeth Hendrickson hosts it in her Agilistry Studio in Pleasanton, CA, and participants come from all over (Elisabeth and I being the most local; the other participants this time around are from the midwest, the East coast, Germany and Sweden).

The week started with a clean slate, no code and no idea what they would create. As the week progressed, the team decided to make a simple JavaScript based game called "Hairballistics". Imagine shooting a cannon, but in this case, the cannon is a cat and the ballistic in questions is a (wait for it...) hairball!

Our app, in real time.

That's what we have been up to during the week, and I got in on the action on Wednesday, going in and exploring the deployed application and features as they can available. What's more, we had a chance to work as a group and focus on the issues as a group and work them in real time up on the screen.

...and you thought *your* monitor was big!

there's been a mild sense of urgency today, since we want to make sure that we get as much wrapped up, committed and tested internally as possible before our deadline of 2:00 PM, since that's when the Weekend testing session will begin. What's going to be interesting about the "weekday" Weekend Testing session is that I'll be doing it up on the projector with the full development team looking, reacting, learning and making changes based on feedback. I think this is a first for Weekend Testing, in that an entire development team will be watching and reacting/learning in real time from  a weekend testing session (it's unique for Weekend Testing Americas, in any event).

2:00 PM came around and even with the short notice, we had about 12 participants join us and test the Hairballistics game. We had a fun session, with a lot of confusion, frustration, discovery, understanding, and feedback (lots of feedback) based on what was in the game at the time of delivery. We were able to cycle through and fix a number of the issues in real time and push two releases during the testing session. We also had a discussion at the end about the variety of testing possibilities that were available to the testers, even with a relatively simple game. We shared the github code base with the testers, and some availed themselves to the opportunity of checking out the code and seeing if they could manipulate the environment to better test certain sections.

The board below shows the issues that are/were in play during the testing session. Cards with pink tags on them are those that were either found by Weekend Testing participants or confirmed by them.

The working board. Pink tags denote issues Weekend Testing discovered or confirmed areas.

This was an interesting experience to do a Weekend Testing session with a full development team in earshot of everything, as well as having the product owner actively participating during the session. It gave me a chance to see better into the application under development, and to also help facilitate and understand the challenges the testers were facing as they worked through the product and tested various areas.

Your host for today.

A Little View Into "Agile Up 4 Here"

Today and tomorrow i will be getting the chance to do something really cool. I get to join an Agile team for a brief part of a code retreat and an active master's session on working with agile teams, Agile testing, and rapid software development.

Elisabeth Hendrickson of Quality Tree Software and Agilistry Studios has a group of people come together each year and participate in a code retreat called "Agile Up X Here" (as you might guess, the first one was called "Agile Up 2 Here" and this is the third iteration of this retreat. We have a number of cool people participating in this event, ranging from product owners, UX designers, programmers, and yes, in my case, dedicated testers.

One team, two tables and just a few days.

Our focus is to create from scratch a simple web game using HTML 5 and JavaScript. We've had a focus of starting from nothing and creating stories, defining acceptance criteria, doing test driven development, pulling stories from the board and working on them, and yes, testing! Today has been interesting in that I've spend the better part of the day directly pairing with one of the developers in a "driver/navigator" capacity. While he wrote code, I had the chance to consider areas we should test, as well as performing exploratory tests on other modules as they are delivered. We also expressed a profound propensity for spontaneous silliness, which made the entire experience a great deal of fun.

Me and Alex Bepple automating the deployment of the app.

For those who want to get in on the fun with us tomorrow, we will be holding a weekday edition of weekend Testing. It will be held tomorrow (Thursday, May 24, 2012) at 2:00 PM Pacific. For this session, we have a simple mission and charter to share: "Be prepared to share your approach to testing what may appear to be a very simple application. Simple does not mean little needs to be done. Single testers, pairs and teams can present their charters, what areas they decided to test, and what they saw along the way. If you are interested in participating, please contact "weekendtestersamericas" on Skype and tell me you would like to join us tomorrow.

My thanks to  Matt Barcomb, Kevin Baribeau, Alex Bepple, Jaime Camphorst, Elisabeth Hendrickson, Dave Liebreich, Rickard Lindberg, and Zee Spencer for participating in this great event. I'm hoping the Weekend Testing session will prove fruitful and successful, and  I look forward to having more opportunities to participate in events like this.

Kindle Fire: My Favorite Non-Network Device

Some of you may be wondering what I mean by this. Of course a Kindle Fire can be networked, it's got a built-in WiFi interface. Yes, but that's not what I mean. Instead, it's now become my favorite way to read both technical and non technical books.

Below is my typical setup at work:

Using a Kindle Fire as a standalone documentation window.

The Kindle Fire is the device sitting just below my large monitor. Why do i have it set like this? It makes for an excellent place to read something technical and place it right at eye level when I'm working. It makes it easier for me to see and compare what is on the page and what I am actively working with. It lets me shift from book to book without my having to clutter up my physical desk or my computer screen.

While those are all good, the best benefit actually turns out to be what I now call the "Zed Shaw Effect" or "Hard Way Effect" (ZSE, HWE, sorry, there's no cool acronym there). What are those? The fact that I can see the text, I can read the text, I can ponder the text, but I cannot copy and paste the text. From working through Learn Ruby the Hard Way, I am now a firm believer that, if you want to learn a technical concept, you have to do it, not just read it, and seriously, you need to type that sucker out. That means making typos. It means cussing a little under your breath. It means re-doing what you thought you did correctly. It means you actually learn it by struggling a bit with it.

There's lots of reasons why a Kindle Fire may be a good investment for you (or hey, fill in the blank with your favorite tablet, the Fire just happens to be what I have). This, above, is my #1 reason :).

Losing the Plot?

There's a long standing statement that we are all familiar with:

"Give a man a fish and he eats for a day, teach a man to fish and he can feed himself for life."
--Confucius

The part that often goes missing from this statement is "teach everyone how to fish… pretty soon you are out of fish and have to move elsewhere". 

Yeah, it spoils the message a little bit, but it's true.

Another statement some may be less familiar with, but one I like a lot, has to do with goals and measuring them:

"When performance is measured, performance improves. When performance is measured and reported back, the rate of improvement accelerates."  

--Thomas S. Monson

On the surface, I totally agree with this, except for one fact… when we measure performance, we can get so caught up with the measurement and fine tuning the measurement and extrapolating the measurement, that we completely kill the performance initiative we were aiming to fix in the first place.

I make no secret of the fact that I consider myself a RescueTime nerd. I use it for my own benefit to see where I am and where I put my time. I started out totally objective in my goals, and I put everything into nice easily defined piles. Software Development work? Highly Productive. Dorking around on Facebook? Incredibly distracting. Personal email? Incredibly distracting. Simple and easy to see what I should be focusing my energies on.

Except it wasn't. What happens when I am responsible for testing Frictionless Sharing on Facebook? Is it distracting or highly productive? When my scripts go out and perform tasks on Facebook, is that productive or distracting? How do I tell the system the difference? It's simple, I go in and I create sub categories that tell me "this is distracting, except for when it's not"… and if you are confused by that last statement, congratulations, it means you are paying attention :).

The point is, we run the risk of becoming myopic if we are simply focused on wringing out what  we think is the most effective use of our time without applying some context to the time we are using. I had this point drilled into me last week when I got my weekly report. Yes, I get these as little pep talks to myself to make sure I know where I'm spending my online time. The overall numbers looked pretty good, including the statement that I was 28% more productive than the average RescueTime user… ahhh, but don't pat me on the back just yet. Why not? I thought to look at the categories. One of the most prominent (and listed as "Very Productive")? Yep, RescueTime itself! I actually spent so much time justifying, checking, fine tuning, and categorizing my activities, that I registered all that categorization as one of my most prominent uses of my time. 

Dumb Dumb Dumb Dumb Dumb!!! 

So lets go back to that second quote again, shall we?

"When performance is measured, performance improves. When performance is measured and reported back, the rate of improvement accelerates."

Except that, if we get too caught up in measuring and reporting, we end up actually wasting time that could be used to actually improve real performance in (fill in the blank category). I'm not saying "don't measure". I'm not saying "don't report". I am saying make sure that the data you are collecting is in the correct context, and then make sure that you are not getting too caught up in the measurement and reporting aspects. Provide enough to make sure you are on track, but remember the whole point of what you are actually measuring and reporting.

Hacking Down a Backlog

Oftentimes, when we get into doing a lot of things, we find ourselves either dropping items we want to work on, or we seem to forget that there are things we still need to do or that we have committed to do. We also tend to get into a mode when we somehow feel that, if we can't devote all of our attention to something, it's out of our reach and it's just not worth doing.

For fans of Seth Godin's "Linchpin", this is a classic trick of "The Resistance". When faced with what seems like an insurmountable task, we throw our hands up in the air and we say "oh, this is just not something I'm going to be able to do" and we hide from the commitment. That may make us feel temporarily good, but in the long run, it doesn't get us closer to our goals or to finishing good work. It also makes us more prone to put off more things that are important, and puts us in the mode where we just work on the things that are urgent (and often not all that important).

So how can we get a handle on all of this? I'm going to dare to pontificate, and realize my pontificating on this is not me trying to say that I am somehow an expert at doing these things, just that I fall victim to them a lot, so these are healthy doses of "Physician, heal thyself" :).

First, I think it's critical to give yourself set times to do certain things and do them in a regular manner. An example is when I produce the TWiST podcast. I know very well that, for me, my most focused time is early morning, so two to three days before the podcast is due, I get up an hour early and devote time to editing, listening, and taking notes. Because this is a regular delivery of mine (i.e. every week we post a new TWiST), it's a standing set of early morning dates, and I know when it happens. The net result, I rarely have to fight for time to edit the podcast, because nothing interferes on those sessions. It's ingrained.

Second, I look at things that are perhaps larger commitments. For one of the Foundations classes, I committed to giving detailed feedback to every one of the students. I am still making good on that one, and it's been several weeks since the last class ended. Life intervened, and it taught me something important. Even the best laid plans can be derailed by other things we have little control over. I also fell prey to the fact that I figured I'd be able to do this in an evening's time. Nope, not gonna' happen. So I had to readjust my expectations and the reality of what I could do. I couldn't review everyone in one night, but I can review one person per day. That means a few students will be waiting for awhile, but at least this way, I can set the expectation, and now I can focus on the one person who needs my feedback at that given time.

Third, if you use a tool like RescueTime to see where your online time goes (and believe me, getting familiar with that can be very informative) you can set goals for yourself in particular areas so that you are alerted when you meet them or if you go beyond a threshold. Do you want to spend a certain amount of time learning Ruby from a particular site? Set a time goal and track it. Do you want to make sure you don't spend too much time on Facebook or Twitter? Again, set a time goal and track it (and pop up an alert that says when you've spent too much time).

Fourth, sometimes we just need to dedicate "now" time to something. I have experimented with two different time focus techniques, and I see benefits to both. there's the Merlin Mann Procrastination dash (10 minutes on, two minutes break, repeated five times an hour) or the Pomodoro Method (25 minutes of focus, with five minute breaks, for the duration of time you want to be focused). Each of these still requires you to commit to timed periods of focus, which leads us to...

Fifth, eliminate distractions if possible, or make time or physical constraints for them if you can. I remember working with a company called WebSense a number of years ago when, at the time, their primary focus was security and filtering of web traffic. One of the phrases I remember one of their engineer's often saying was "You can't have it now, but you can have it later". This was at a time before video and audio streaming were as ubiquitous as they are now, and doing these things could be hugely draining on a corporate network (they still are, but nowhere near as much as back in the late 90's when these technologies were still in their infancy). The idea they fostered was to either put a time constraint or a physical constraint. For me, this might be "it's OK to spend as much time on Facebook or Twitter as I want, but I have to be walking on the treadmill desk to do it". It could also mean "personal emails will only be answered between the hours of 5:00 p.m. and 7:00 p.m." or any other number of areas. By doing this, we force distractions into scheduled blocks, and then we free ourselves of having to deal with them at other times.

Again, I come back to these things time and time again because I'm often the most guilty when it comes to dealing with these areas (or not dealing with them). We can't have it all, we can't do it all, there are no more than 24 hours in a given day, and those hours go by way faster than we want to believe. Taking small steps to whittle away at a backlog will one day get it down to a reasonable size. Yes, one day. It's not going to all disappear at once. The sooner we all get used to that, the sooner we can accomplish the things we need, and want, to do.

Summer QAmp Brain Dump: Need BRAAIINS!!!

It probably has not gone unnoticed that I am posting less frequently than usual. There's a few reasons for that, and one of them is that I am trying to get all of my ideas down for the education modules that we will be preparing for Summer QAmp. I had initially planned on writing everything out, and posting it, and then massaging it down to a useable format. The past several days have taught me that that is going to take a long time, and it will give a very limited amount of time for feedback and review from others.

Because of this, I've decided to take a different approach, and I hope that you all will join me. We are discussing the elements that we want to present in the education materials over on the Association for Software Testing's EdSIG forum. At the moment, you have to be a member of AST to post in the forums, but we may well change that for this initiative, so as to get as many of the interested contributors as possible to be able to post.

In the meantime, though, the forum is open for reading to anyone who wants to participate, and if you would like to have your ideas included, please reply and let me know your interest and areas you would like to contribute.

Additionally, if you would prefer to communicate with me via email, you are welcome to send a message to me directly at mkltesthead (at) gmail (dot) com.

Cucumber Nerds: Can Color and Pipes Coexist?

I think I have gotten to a point where I have done all I can do to try to figure out a problem, and I'm coming up empty handed, so to my wonderful tester friends out there, especially those well versed in Cucumber, I need your help.

In a perfect world, I would come up with hooks to handle weird exceptions, and I would also have clean running tests every time. However, this is not a perfect world, and right now, getting the tests to reliably work is my priority. Also, I want to be able to rerun tests that fail and see if they are spurious failures or if there's a real problem.

How did i do this? I made a shell wrapper that would tee the output of the console to a rerun file, and then I would capture the failures, recreate a test suite of just the failed scenarios, and run them individually. Repeat until we get a 100% clean run or we confirm that something is genuinely broken.

So what's my problem? The lovely red/green/yellow color scheme that shows me what's happening at a glance disappears, replaced with a monochrome representation of all the steps. Do the tests run? Sure? Does the rerun whittle down my errors until I get to the essential problems? Yep, it does. I just want to have my cake and eat it too, if possible.

If I run without the rerun script (i.e. sans tee):

If I run with the rerun script (i.e. with the tee):

I get that this is because the system is trying to be smart and not deal with colors because the output is going to a pipe and not to the traditional console. My question is, how can I make my system stop being so smart? the -c (force color) option doesn't cut it.

Learning to Tell Different Stories

Motoko Kusanagi from "Ghost in the Shell"

One of the things I have enjoyed with my children is sharing my love of Anime with them. Anime, for those not familiar, is the animation style that developed in Japan and has had a varied level of interest in the U.S. over the past 50 years.

 I first became familiar with Anime through shows like Kimba the White Lion, Speed Racer and Gatchaman (which we knew in the states as “Battle of the Planets”). This was my early introduction to this style, and over the years, it’s become better known and more titles have become available in the U.S. over the past few decades. Unlike in the U.S., where animation is often seen as programming for kids, Anime is developed for all ages and some is as gripping and intense as the most well produced cable television series and, in some cases, motion pictures (for those interested, some of my favorites are "Ghost in the Shell", "Cowboy Bebop", "Fullmetal Alchemist", "Neon Genesis Evangelion", "Clannad" and "Wolf's Rain").

Why am I bringing this up on a testing blog? It’s because, as I’ve been sharing these stories with my children, I’ve enjoyed answering some of their questions or finding out more about some of the questions they ask. One of the things that I have been sharing with them is the fact that Japan, though in many ways a modern industrial culture, has very different cultural traditions as compared to the U.S. Key to that are their religious and social mores. Many of the references made in these shows are things that are very familiar to us in the U.S., but there are also subtleties that are very Japanese.

We are used to many of the stories that are told in the “Western” tradition being told from the perspective of Judeo-Christian values. These values, mixed in with Greek philosophy, make up the bulk of the stories and the legends that have come down to us. The fairy tales and literature that we are most familiar with have many things that we would look at naturally; good overcomes evil, the hero saves the day, the protagonist generally achieves his goal, and they all lived happily ever after.

The stories that appear in Anime do not always flow this way. Often evil does succeed. Often the protagonist dies.The resolution of many series is left to be ambiguous at best. Frankly, I enjoy that. I like Anime because it helps me look at different cultural stories and see what is common to the human experience, but more to the point, I like seeing what is different. Some of my friends who have grown up in Japan and who indulge me in talking about some of these stories have told me that there are maybe a hundred little things in any given series that would go over the head of an everyday Western viewer. There are inside jokes, idioms, aspects of the way characters are drawn, interact with each other, look at each other, and things that we would take as insignificant quirks. To those who have grown up with it, these small quirks are actually very significant. I like being clued into these things, because I can view the shows again after several years, and I see new aspects I never knew about. They were always there, but I was not trained to see them.

Today, we as testers have similar opportunities. When we make a shift from one product to another, we also get the chance to see the stories that are universal. But we also get to see those things that are very unique to their own industry, niche, market, or worldview. If we think that knowing a bit of testing “best practices” will carry us over to all circumstances, we are very much mistaken and we will miss a lot of stuff. We have to get used to those new stories, and learn the nuances that make them unique, and in turn understand the underlying culture and how that underlying culture informs the stories. Doing that will not necessarily make you an expert in every domain, but it will definitely give you a better chance of getting closer to that goal in the domain you are currently working in.

Cross "Training": Shaking Up the Home Office

This may either turn out to be a corny diversion or the healthiest thing I've ever done for myself. I'm not entirely sure which :).

One of the factors that I discovered when I started pouring myself into doing a lot of testing things is that my fitness levels started to drop. I would get out and skateboard when I could or ride my bike, but these activities make my wife anxious. Needless to say, my breaking my leg last year using my skateboard as a commute vehicle did not give her much to boost confidence in my doing these things, and rather than risk friction in my marital bliss, I've complied. This does, however, mean that the opportunities to get out and do structured exercise are somewhat limited. Each time I think of things I want to write, test, prepare, read, or do, I have to decide to deliberately stop what I'm doing to go get some exercise. It's one or the other... or does it have to be?

There have been a variety of stories about the "brogramming" movement (if you're curious, put "brogramming" in your preferred search engine and enjoy or cringe at what you read). Regardless of the silliness of the various memes related to "brogramming" I will admit that the attention to fitness did appeal to me. What's more, it was through this that I started to see lots of links to a variety of "treadmill desks". Kitschy? Sure, but at the same time, very intriguing. After I got over poo-poohing the ridiculousness of a treadmill desk, I remembered that one of our Sidereel founders had a treadmill desk in our old loft on Jessie Street. With this thought in my head, I asked him about it, if he still used it, and if he had any thoughts about what to do.

He made a few recommendations. First, it's easier if the treadmill in question has support arms that are parallel to the floor and at a reasonable height. From there, a piece of wood, some C clamps and you are golden. One suggestion he recommended to me was that I'd want to invest in a high end treadmill, because the entry level models would not hold up to the abuse of using it for hours each day.

With that, I made some inquiries, checked out some models, and since I wasn't entirely sold on this idea, I figured that I would look to find a refurbished higher end treadmill rather than buy one brand new. I'd hate to spent a grand plus and then find out this is a white elephant of an idea, and then the "treadmill desk" becomes a "treadmill clothes rack", and a rather expensive one at that. I met up with a guy that goes to auctions and purchases items from gyms that have gone under, then he fixes them up and resells them. Thus, I was able to get a pretty good high end, though older, Precor unit for $175.00.

The next step? Making a desktop surface for as little as possible but still be functional. That was done by taking a trip to Lowes and picking up a 15" x 36" white melamine shelf, 4 eye screws, and two 24" bungee cables. The eye screws were put in an inch from the front edge on the sides, and an inch from the sides on the back. this way, I could criss-cross a par of bungee cords from the eyes and hold them down to the cross bars and make for a solid and stable work surface. I made one additional adjustment in that I used two bath towels and rolled them up on the bars so they could act as a dampening mechanism for the machines. All in all $175 for a refurbished treadmill, $25 for the parts to make the desktop, and now I have a way to read, study, dork around on Twitter or Facebook, and rather than feel like I have to choose getting up and walking around vs. sitting down and doing work, I now have the ability to do both. The benefit to the system that I've put together is that I can remove the desktop easily and use the arm bars for a more vigorous workout if I so choose.

I gave the system its maiden voyage last night, and ended up spending about two hours walking at 3 mph or so (maybe a little slower at spots; 3mph is about the maximum speed I can maintain and still type). Up side, I got a lot done (including editing the most recent TWiST podcast while walking :) ). Down side, I'm rather sore this morning. Also, I discovered that the better way to work with the walking desk is to have one system at a time up on the desk. By having two side by side, I was positioning myself at a bit of an angle depending on the machine I was working on, and it torqued the belt a little bit. Nothing serious, but I ended up skidding the belt off to the side and needed to adjust the treadmill to get it back into regular operating order again.

So will this be the holy grail to getting me back into being fit and healthy? Will it be a silly diversion that I don't follow through with? Time can only tell on that, but so far, it seems to be something that's workable, interesting, and enough of a novelty to shake up the system. Whether it will have staying power is anyone's guess, but I'm certainly willing to give it my best try.