The Power of Association: When "Discovery" Became "Interstella 5555"

This is a bit of an indulgent post today, but it made me chuckle a little, and I thought there was an interesting lesson in all of this, so here's hoping you enjoy the somewhat tangential journey.

For starters, I'm a fan of a broad cross section of music. I love lots of different styles, and lots of different genres. I especially like music I can dance to because, well, I like to dance. Thus, when Daft Punk came out with the highly electronic and variable album "Discovery" in 2001, buoyed by its auto-tune pioneering track "One More Time", I thought it was a fun, quirky and danceable house album. From there, I just let it recede into my memory of everyday music.

Move forward to the end of 2003. Daft Punk and Japanese animation legend Leiji Matsumoto (he of "Space Battleship Yamato" fame), collaborated on several music videos for the tracks on Discovery. In fact, all of them. The net result of this collaboration was the fun, quirky and memorable Anime film "Interstella 5555: The 5tory of the 5ecret 5tar 5ystem".

My daughters love this movie! they have watched it several times, and know all of the key points to it, they know the story of the abduction of the blue band from their home-world, of Shep and his determination to rescue them, and all of the songs that go with the saga of the Creschendolls as they make their way through the story.

I had some fun asking them about various songs and why they liked them. Invariably, they didn't say anything about the beat, or about the structure of the song, or the melodic elements. They mentioned what was happening in the actual movie. In other words, to my kids, Daft Punk's work is incidental. It's the images that make the experience. To me, it's the other way around. The music is what fascinates me, and the imagery adds a layer of fun candy to the experience, but it's not the experience. Why? Because I experienced "Discovery" away from the context of "Interstella 5555". My daughters never have. To them, Discovery is Interstella 5555!

For years, I've been interested in how we associate memories, emotions, and feelings with our first experiences with something. It's why changes can be traumatic to some people, even if the changes are arguable for the better. Likewise, if our first experience is with something that came later, we may have less sympathy with those extolling what used to be. I explained to my daughter when I was a teenager there used to be a common argument among Iron Maiden fans. Who was the better vocalist? Paul Di'Anno or Bruce Dickinson? To me, on a purely aesthetic level, Bruce Dickinson is the more accomplished vocalist. On a purely emotional level, he doesn't hold a candle to Paul Di'Anno. How can I say that? Because it was Paul who emotionally connected with me as a singer when I was a young teenager. Bruce came later, and because he was not part of the initial experience, he was always looked as as an "after element". I didn't associated Bruce with Iron Maiden the same way I associated Paul.

What does this all have to do with testing? We talk a mean game about context and switching context when it's needed, but we have a very large problem to overcome with many people, and that is the fact that it is often difficult for their brains to make  contextual jumps. Associations are powerful things. We often don't realize that our contexts are built based on associations. Those associations can be physical, auditory, tactile, emotional, psychological. They can be good or bad based on our immediate experiences, and sometimes, we have a hard time seeing one association as being more or less relevant than another. the trick to overcoming and changing contexts is being willing and able to mentally break with associations.

So the next time you find yourself wondering why someone might be looking at a product or a feature a certain way, or with a certain bias or slant, ask yourself if there are any lingering associations with the feature or element in question. The more effectively you can determine the associations, the more likely you are to be able to figure out how to get beyond them and look at them differently.

#Agilistry or #PNSQC: Come Hear Me Speak!

This is a little self serving, but hey, I did the work for the papers and presentations to develop the topic, I want to have people hear it. That's not too much to ask, is it :)?

Next Thursday, September 27th, 2012, I will be giving a talk at Agilistry Studio in Pleasanton, CA on "Getting the Balance Right". This is an extension and follow-up/reboot of the talk I gave at CAST 2012 in San Jose.

This talk is being sponsored by the Agilistry Meet-Up Group, and there's still a spot available, so if you would like to attend, go and do your Meetup magic and come by :).

Some may be saying "that's great, but I won't be in the Bay Area on the 27th". Well, for those of you who will be attending PNSQC in Portland, Oregon October 8-10, 2012, you'll get a chance to hear me deliver this talk there, too, albeit in a modified format.

I am confirmed to be one of the presenters during the Poster Paper presentations, so I'll be delivering an "evevator pitch" of these ideas plus examples based on questions and feedback. Consider the Agilistry talk the full presentation, and the PNSQC talk a more tailored and dynamic presentation that I'll be delivering several times. There's also a chance that I may be able to deliver the full talk at PNSQC; we'll see how the final schedule shakes out.

Also, I will be participating in PNSQC's "Birds of a Feather" talk series on Monday afternoon about testing challenges and specifically how Miagi-do uses them to help develop and mentor testers, and how you can use the same techniques when creating test mentoring for your team (formally) or to improve and develop your own craft along with a few friends.

Hope to see you there, whichever "there" happens to work for you!

Pulling Out of the Shadows

Image from http://douglascootey.com/

The next few paragraphs should be a blinding flash of the obvious.

For those who have followed this blog for any length of time, you will notice and you will know certain things about me. You know I have a high energy level. You know that I am involved in a lot of endeavors, and enjoy those endeavors. You know that I like to write, sometimes a lot. You know that I enjoy investigating various aspects of life and the way things work. You also know that I believe strongly in being an open book about my life, my journey and the challenges that I face. So here goes, and if this is a surprise to anyone, you really aren't paying attention...

I am an adult with Attention Deficit Hyperactivity Disorder (Adult ADHD).

Nope, no self-deprecating humor this time. No jokes about “squirrel” or “shiny” or any of that. I have ADHD, and for the past 27 years, I have done my level best to try to deal with it in a variety of ways. The key point is that, for those 27 years, I have left out one piece of the puzzle, and entirely on purpose… medical treatment, and specifically, medication.

When I was younger, meaning around age 7 or 8, I first went on medication for ADHD. Like many kids in the 70s, I was put on Ritalin (Methylphenidate Hydrochloride) to help keep me under control. It worked amazing well in areas of focus and information retention, as well as getting good grades. What I hated about it was the person it made me; moody, angry, sullen, withdrawn, introverted, and isolated. I hated the latter elements so much that I was willing to do battle against the very benefits it provided. Over three cycles of my school life (elementary school, junior high and then in my first years at college) I used Ritalin. Each time, the same things happened. My grades and performance improved, but I became a raging tool in the process. Ultimately, I decided to just live life without the meds, because I didn’t want to be “that guy”, even if “that guy” could focus and be extremely effective.

Fast forward to today. As a part of playing with “The Hours”, investigating issues such as expectational debt, looking at my time commitments, my energy levels, where I choose to focus my time, and how it ultimately gets distributed, the tester in me decided it was time to do an even deeper dive. Enough with the immediate and superficial; let’s look at the past 20 years of my career! I spelled a lot of that out in my posts about meandering through 20 years of software testing, but I realized there was a lot I was leaving out. Not deliberately, but because I wasn’t willing to face what it meant to examine it at the time. Many of my career choices, the activities I participate in, all of the ups and the downs and the very way that I like to work (as a lone tester), all make sense when you put one phrase in context with all of it: Untreated Adult ADHD.

So what’s made me decide to do something about this now? I have three people indirectly to thank for planting this seed in my head and convincing me to act on it. Those three people are Merlin Mann, Scott Hanselman and Iris Classon. Merlin, as many of you may well realize, figures into lot of the things I talk about, because he’s where I heard about a lot of this stuff first (Expectational Debt deserves to be a service mark of Merlin Mann as far as I’m concerned ;) ). In one of the earlier Back to Work podcasts, he talked very directly and specifically about his own challenges with Adult ADHD and years of not treating it, and finally deciding to treat it. Scott Hanselman, in addition to being a vocal tech pundit, has also been quite vocal about his own challenges and issues with diabetes, and the fact that he’s been willing to put it out there for everyone to see first hand. He said he could have hid it, but why? Finally, it was on Scott’s podcast with Iris and her openly discussing her challenges with ADHD as a child and as an adult that made me decide “there’s no reason for me to hide behind it any more.” Besides, if I do hide behind it, it has to be the world's worst kept secret.

So today, I made the first steps into the fray of this. My primary physician just made the referral to the psychiatry department so that I can get this underway. Am I nervous? A little. At the same time, the tester in me would never forgive myself if I didn’t at least explore this avenue of who I am and if I can do something about it. It may turn out that I’m actually fine, and that I’m making much ado about nothing. If that’s the case, then I’ll have other avenues to explore. If I am diagnosed, there are a lot more varieties of treatment today compared to three decades ago. Also, this time, I’m not the sullen kid resenting the fact that I’m “different”, and wishing beyond hope that I could just make it go away. Instead, I now have the opportunity to actually look at this for what it is, and potentially change how I interact with my own brain. In a way, I’m excited about that. Perhaps there are benefits to being older, wiser and a bit world weary. Because I'm all of those, I’m willing to take it for what it is, and deal with it non-judgmentally, with open consideration as to where the road may lead. Like all good testers should :).

SF Ruby Book Club!

I could jump for joy about this :).

For the past several months, I've been looking at the trove of books that I have been reading, considering, looking over, and occasionally reviewing, reconsidering, and otherwise just looking at when I need them. What's missing very often is the human interaction with others. When it comes to fiction, it's easier to find people interested in talking about the books they read and what they get out oif them. Technical books are a little more challenging, because of two major issues. First, it requires a group of people be interested in the topic and the technology. Second, there are many people who don't want to engage in these discussions because, honestly, they are afraid they will be found to be technically lacking. It's like the guy who snowboards and brags about his prowess, but somehow never gets the opportunity to go up and ride with you. Or on the other hand, you invite someone and they are not the "braggadocious" type; they're just afraid that they won't be able to keep up, so they decline or refrain from participating.

Well, the San Francisco Ruby Meetup Group is starting a Ruby Book Club, and I'm all for getting into it. What's more, I'll start with the following:

"I suck at programming. I can read code, I can see what it's doing, I can even make modifications to code that already exists. Put me in front of a blank text editor, though, and say "write something", and I'm toast!"

There, that wasn't so hard!

Now I've set the expectation. I'm no great shakes at this. I feel the same about Ruby as I do about Spanish and German, two languages I studied when I was younger. I learned the rules, I learned a lot of words, I learned how to extract out of the air what I heard and read and process it and get the gist of what it meant, but I struggled with the fact that I never got good at it, and never to the point where I could converse freely. Now all these years later, I'm having the same discussion when it comes to programming, and I've decided something. I can do better.

So to those in San Francisco, I hope you'll come out and participate with me in this little adventure. It seems well suited to the goals of TESTHEAD and what I've done in the past. The first title the Book Club is considering is "The Practical Programmer", which coincidentally, is a title I recently bought out of curiosity and a desire to understand "how the other half lives". Looks like it will be more than just a curiosity now. Who knows, I may just be able to make "five new friends" (or more) in this process, and maybe, just maybe, I'll be able to get from being a bystander who hears a little here and there to one able to be part of the real conversation.

The Five Friends Rule

This next post may come off as crass, but I assure you that that is not at all my intention. Instead, I state this because I absolutely believe in the power of this idea. Over the years, I've looked at a lot of ways to figure out what has worked with me when it comes to a goal, an aspiration, or something I truly wanted to be. Those goals have fluctuated, and they have made themselves manifest at different times.

- In my youth, I wanted to be a martial artist.

- In my later youth, I wanted to be a fashion model.

- As a young adult, I wanted to be a musician.

- As a slightly older young adult, I wanted to be a great snowboarder.

- During this same time, I wanted to have a bodybuilder level physique.

- As a middle aged man, I wanted to be an excellent Boy Scout leader.

- These past few years, I have wanted to be a Rock Star level tester.

I made at least some progress in all of the areas, and many of the goals I made some pretty good progress with. Martial arts, modeling and bodybuilding were moderately successful endeavors, but ultimately they fell by the wayside. The musician, snowboarding, scouting and testing aspects of my life, however, I was able to do much more and go farther in those than I ever imagined. Why? because I surrounded myself with PEOPLE that shared those passions.

From this, I've come up with something I call the 'Five Friends Rule". Think about something in your life that has a "fitness" quotient to it:

-  physical fitness
-  financial fitness
-  spiritual fitness
-  knowledge of a given area
-  performance in a given area

If you'd like to know where you reside in any of those spheres, if you were to look at your five closest friends, and examine those areas, it's likely that you would be the average of those five friends.

There's ancient wisdom in this. It's in the Aesop's Fable phrase of "birds of a feather flock together". If you hang out with the "same old crew", five years from now, you will probably be roughly in the same place as the "same old crew". Charles "Tremendous" Jones is the originator of one of my favorite quotes:

“You will be the same person in five years as you are today except for the people you meet and the books you read.”

The books we read tend to open us up to new ideas and ways of thinking (and for today's world, I would also include my Twitter stream and my blog roll). The people we hang out with, though, will help us determine whether or not we actually do something with the knowledge that we have learned.

Here's an example. You feel frustrated that you are not in good physical shape. There's lots of evidence that points to not just what you do and what you know, but who you hang out with and interact with, that will determine your overall success. If you hang out with five relatively inactive people, in the long run, your physical fitness will likely be in the average of those five closest friends. Why? Because for them to be your closest friends, they are the people you actually interact with!

To make a change that will last, very often it means, at least in that sphere, you make a new set of closest friends, or to be more kindly worded, you hang out with people who share that particular goal! People who will encourage you, inspire you, and make you want to excel and achieve. Why is this? I believe it's because the interactions are what make the long term behaviors stick. Could we achieve it all on our own? It's possible, but it's a lot more likely with a "social network", and the most powerful social network is basically the five people you are closest to.

I enjoyed being a singer, but it was my various band mates who drove me on to get better, write better and perform better over nearly a decade I tried to be a performer. My competitive snowboarding exploits were phenomenally encouraged by people of various ages, some younger and some lots older, to get out there and push myself to the limit each year. I became a solid scout leader when I committed to learning from other solid scout leaders and getting to know them better and how they were successful (which included getting myself into the Wood Badge community, and that deserves a post all its own :) ) and finally, I have made quantum leaps in my sphere as a software tester in just the past two and a half years because of the people that I have had the pleasure to interact with and call my friends. Had I not met and interacted with these people, it's likely I'd be in a very different place right now, doing very different things.

This can kind of be summed up, and now I am being a little crass for humor's sake:

- If you want to be better read, hang out with people who read a lot of books.
- If you want to be in great physical shape, hang out with people who exercise a lot.
- If you want to be wealthy, hang around with rich people.

OK, that last one is indeed crass, but it's not entirely wrong, either. Let's say your dream was that you wanted to create a successful start up. Do you do that by dreaming about it? Sure, a little bit. Do you do it by executing? Lots more of that, to be sure. By surrounding yourself with others who have done similar things, and have life lessons that will help you achieve your goals, do you think you have a better shot at being successful? Absolutely!

If "birds of a feather flock together" is the ancient message, perhaps the modern day equivalent to this is "either you change your organization (you foster the change among your friends to bring them up to your level in [fill in the blank]), or you change your organization (by finding people that share your passion for [fill in the blank] so that you can be successful at it).

Note: I am in no way advocating that you abandon your best friends if they don't share your interests in a particular area. There are lots of facets that inform our friendships with others, and to put too much emphasis on one area would make us all very shallow friends, indeed. Still, if you really do have aspirations to do something big, to change something on a macro level in your life, much of the time, the company you keep will ultimately determine how far you get.

AgilePalooza: A Semi-Live Blog

I'm sitting in a conference room in Santa Clara with my Parent Company, Rovi, and a number of other participants, and we are having a private session of AgilePalooza. This was prompted by the fact that  Rovi, as a whole, has decided to embrace Agile. Sidereel has been "Agile" since day one and before we were acquired, but Rovi has a number of different product lines, many of which are from acquired companies. Because of this, they are making a much greater leap than the one Sidereel made. As such, I thought it would be interesting to see how this whole "Agile" thing is being taught for those who don't already play with it. Seeing as I was thrown in the deep end last year and had to make it up as I went along, I also wanted to see how this is "supposed to work". My thanks to the Sidereel team for giving me a day to explore this.

Our first part of the day started with Steve Davis of Davisbase Consulting, and he is describing the philosophy behind Agile, but more to the point, the stumbling blocks that get in the way of companies successfully implementing Agile. Steve made a case that, while may organizations provide feedback as to what works and what doesn't, there's a huge part of the feedback loop missing… the companies that tried Agile and bailed on it. The importance with Agile and getting a team to be effective isn't really about process, it's about where they ultimately want to be. "Begin with the end in mind" to borrow from Steven Covey's second Effectiveness Principle.

A challenge with adopting Agile is that a team, a company, and a culture needs to believe that it's going to actually work. To that end, getting involved early and learning early is critical. Believing that you can be Agile is good, but it's not enough, and more to the point, it's not a one time event. Teams need to work continuously to get better and actually understand what they are doing, what they appreciate, what they hate, and what areas can be improved upon. There will be challenges, and there will be cultural issues that will either get masked by the process, or it will be ripped bare and made public by the process.  How we handle them is important, and often it's very incrementally and iteratively.

I'm impressed with how the concepts of "Shuhari" (Obey, Digress, Transcend) and "Kaizen" (Continuously Improve) come into play here. Shuhari is a concept within martial arts where learning and development along with mastery often supersede the elemental forms that we fist slavishly follow. Mastery is more than rote following. Sometimes it requires transcending and changing the old forms. Kaizen is the idea of continuous improvement, the actual doing of the concepts that make up Shuhari (or Agile, in this context). Mastery, though, comes down to doing, and doing a lot. Just slapping a label like Agile onto a company will not make it Agile. Habits may also involve people differently. In my own work, I have opportunities to "play by the rules" of Agile, but sometimes I have to make up my own rules just because of the nature of what I do. Just because there is a system, doesn't mean that being a slave to that system will be effective. Perhaps this is a difference between lover case "agile" and uppercase "Agile". It's not a one size fits all situation; some things may have to be adapted. Regardless, we can't just pay lip service to it, we have to actually do it. The Shuhari style terms for Agile are "Knowing, Doing, Becoming".

The next step goes beyond the process, and involves the people. Ultimately, it's the people that make an Agile transition effective. It's common to have people who make the move to Agile still keep their same infrastructure as before. In many ways, this alignment entrenches old behaviors and habits, because very often we are beholden to the people that we interact with, rather than our involvement with an arbitrary ideal team concept. If you must "measure" to help make your teams effective, try to utilize positive measurements. Are you a good team? Do you have good team members? Are you individually good at what you are supposed to be good at?  Your customers will determine the first one. Your team members may help determine how you are doing with the second one. Ultimately, number three is entirely up to the individual.


We are social beings. Social community is more than a buzzword for networks like Facebook, Quora or Pinterest. It's a real currency and the way that we are genuinely motivated. When we learn socially, we learn dependably and often better than any other manner. Our social connections in our organizations will often drive the way that we learn and how we apply what we do. We also do things less for the work, less for the sake of it, and much more for the love (or at least care and appreciation) of our immediate team.  Ultimately, though, if you must measure, measure based on the customer and how happy they are with what has been delivered and continues to be delivered.

After the primary presentation. we had a round table discussion specific to questions asked by the attendees, and some discussions about challenges faced by those looking to implement Agile. One of the most common is impatience. Interestingly, it's not executive impatience that causes problems, it's the practitioners' impatience. This is where having a clear and strong vision, and a realistic time frame is critical. Additional to the impatience is to try to figure out how to determine if we are actually making real progress. The answer is based on the features and whether or not they are actually being used by their customers. By comparison, when customer satisfaction is actually measured, a lot of pet projects go by the wayside. Though a long term goal is to get beyond looking at the end of the quarter or the current stock price, the truth is, those are relevant measures, and if both are declining, it's hard to keep a transitional initiative alive and thriving. Agile transitions don't happen overnight, especially for organizations that have set  formats and established cultures. It takes years to develop that, and often, it will take years to develop out of it. If you have to measure for metrics, measure for the change you are hoping to achieve. Also, metrics are not set in stone, nor should they be. Once you have established a pattern, get rid of the metric. 

As we were discussing dependencies, I couldn't help but chuckle when the facilitator asked what some "best practices" were to help resolve issues with those dependencies (I refrained from saying "there are no such thing as best practices, just good practices in context!", but I figured I was in a different crowd, so I didn't say it there... I'm saying it here though ;) ). This is a real problem for an organization that has products that depend on each other to make a cohesive strategy. Sidereel is in many ways a standalone product, but as far as Rovi is concerned, its an integral part of its digital media offerings. Things we do have an effect on other product lines now, and thus, Sidereel is a dependency for other initiatives. It's interesting to be reminded of that fact. Dependencies crop up all the time, so it's better to be aware of them and how to work with them, rather than having them become a stumbling block. Keeping on top of issues and dependencies can help make sure that the challenges associated with them are minimized.


We had a discussion of splitting focuses and projects, and I like the idea of "one backlog, one team". Instead of having side projects and products, the team has one back log, and that backlog is visible to all. This way, it becomes possible to see all of the work that the team is facing, and how to decide what they will prioritize and what will get worked on, and what won't be. Transparency is critical; having too many hidden items can crush a teams momentum. It also helps set up the real expectations for the team, so that everyone can address the work load in a practical way (dealing with Expectational Debt; I like it :) ).

A great deal of the later discussions have been specific to the tool implementation and how to utilize the tool (VersionOne is a tool vendor, and they are sponsoring today's event). While a lot of the discussion is being spent on how to implement  Agile using VersionOne, there's still some good ideas being discussed and some perspectives I have not considered. Issues such as using Scrum in with distributed teams, how to carve up one large team into multiple smaller teams, making sure that a key technology is not being modified by two separate teams simultaneously (talk to each other!), and how to get multiple scrum teams to communicate. One interesting question that branched into a good discussion was how we could get more action out of a retrospective. That's a topic that could take an entire day, but  it gave me a chance to share a good practice we use called a mini-retro. rather than wait two weeks or an entire month before a retrospective, we have a mini-retro every week, with simple parameters and the goal of getting a small number of action items to focus on for that coming week, rather than have a large list of action items that might prove to be overwhelming if taken on at a regular retro.

Following lunch, I had a chance to talk to the vendors and consulting team for VersionOne, and discovered that we knew a lot of the same people (my ears perked up when one of the consultants made a comment and quoted Dale Emory :). When he saw me perk up, e decided he had to find out how I knew about Dale, and a lot of great talking (and some laughs) ensued.


It's been fun, thanks for playing along.

The Ultimate Pair Test: Teaching My Son to Drive

The past few weeks have been interesting, in that I have had to overcome a natural fear and put my fate into someone else's hands. This someone else happens to be my 16 year old son. He has embarked down the road of learning how to drive, and I am the one that is doing most of the drive time chaperoning and experiments/instruction. As I was looking at this, it struck me how like pair testing it is, and how, so often, we as the senior member can get frustrated at times with the efforts of the junior associate we are working with.

As I get into the car, I realize that there is a rather large checklist of things to deal with. Case in point, this morning my son needed to get to an early morning meeting before school. Rather than just go along with driving him, I gave him the opportunity to drive himself, with me in the car. As I had him get started, it brought to mind immediately the quantity of steps that I do automatically every time I get into the car. Adjust the mirrors (actually, I don't; they're already set for me), put the key in the ignition, fasten the seat belt, turn on the lights, check the gas, take off the emergency brake, run the wiper once or twice to clear the dew/moisture off the windshield, and that's all before even pulling on the gear shift to put the car in gear. Automatic steps to me, but somewhat foreign to my son. It amazed me how many things I had to remind him to consider, and even with all that, because it was dark when we left, it wasn't until we arrived at the destination that we both realized that he hadn't taken off the emergency brake (oops!).

The beauty of pair testing, more than just having two eyes on the the same product, is that we very often get complacent in our knowledge and those things that we do automatically. It was humbling to think of all the things that I had learned over time to do the steps necessary to drive a car. Things that I take totally for granted, but that, when put in the hands of a novice, can be quite overwhelming. I also think of this when I consider my challenges and adventures in programming. There's so many moving parts, so many things to consider, so many aspects that tie together and, if I forget one, there will be issues. Well, the same goes for driving a car. As I watched my son inch out into traffic, get onto the freeway, get off on exists, approach stop signs, park along the side of the curb, I was flooded with so many details of what I should be telling him, and truly, those details don't really help very much in the moment. Yes, he has a lot he needs to remember, but throwing more and more things at him won't help him remember more or faster. The skills have to come in time, with practice and with effort, and I have to be there to encourage him along the way.

Testers, we have great opportunities in our work days, via forums, through Twitter, and through programs like Weekend Testing and SummerQAmp, not to mention AST BBST classes and other avenues, to help teach our "children" and our "siblings" how to drive. Being the passenger in this situation is nothing if not educational. We really see how rationally and calmly we can explain situations and avenues/challenges the driver may face (or not so rationally and calmly in some cases). Substitute the word driver with tester or programmer, and we see that the same situation applies in those spheres. We have a lot if information to impart, and our "drivers" have to figure it out. If you feel frustrated or wondering if they are getting it, put yourself in the passenger seat of a first (or second, third, or fourth) time driver and think of how they are processing all of the areas they have to control. Feel a little more compassionate? Great, now bring that back to your testers and programmers, and remember, they have to learn the rules of the road, too.

I am Sidereel (And So Can You!): Come Work With Me!!!

This may seem an unusual entry, in that I have typically avoided talking too directly about where I work and what that all represents, but this serves a different purpose. We are actively recruiting software developers and other roles within Sidereel at this time, and to help with this, our Director of Engineering asked us if we'd be willing to write about Sidereel and what we enjoy, find interesting, or otherwise give a reason why we like working here.

First, it may be helpful to explain what Sidereel is. We are a company that is dedicated to television, movies and WebTV shows. We provide our users with a one stop shop for television shows of various networks, providers and countries. We help you discover, watch and track shows that interest you. We make it possible for you to share that information with others if you so choose, and we make it possible for you to keep track and be alerted when the shows you want to watch are available or will air. We give you tools to do that from your computer, your smart phone, your tablet or your living room Internet television connection. We are a Ruby on Rails development shop and use the variety of tools in the Ruby ecosphere to develop and test our products. Some of our musings on software development and some of what we do can be seen at "behind the reel", our tumblr engineering blog.

For myself, I can say that I am in a different place than many of the people that Sidereel is looking to hire at this time. I'm a Software Tester. Not a Quality Assurance Engineer, or Quality Analyst, Quality Specialist or some other buzzword / title that is often abused and misunderstood. A Software Tester. My official title is "Senior Tester"; Tester" because that's what I actually do, and "Senior" because I've done it a long time.  There's the first clue about what I like about Sidereel. They get and appreciate testing. It's not an afterthought, it's baked into everything they do. As an Agile shop, they believe strongly in the ideals and practices of Test Driven Development, Acceptance Test Driven Development, Behavior Driven Development and emphasize testable design, testable code and making it possible to do my job effectively. 

Another factor I like about Sidereel is its overall lack of bureaucracy. Our structure is pretty flat, due to the fact that we are a small group. The engineering team has a number of developers, a dedicated tester (me), and a director. That's it. We don't need to go through a lot of hoops to implement changes or try out ideas. We use Agile practices to develop stories, estimate the time it takes to do them, pair program to implement them, review our progress regularly, and encourage change from within. Along with this is a strong sense of autonomy. No one is going to tell you exactly how to do your job. Micro managers and those who like to be micromanaged need not apply. People who value freedom to explore, investigate, and learn will likely thrive here. Those who like to coast will likely find it painful to be here. Those who want to keep learning, focus on improving and growing, and getting encouragement to step up, will probably dig being here.

Sidereel is part of a larger corporation now. When I first was hired, it was a standalone start up. Now, we are part of Rovi Corporation, which owns and operates a number of brands associated with digital media. The AllMovie, AllMusic and AllGame guides are part of Rovi, as are Sonic, DivX and numerous other properties. It's a company that has a reach around the globe, yet at the same time has seen to it that Sidereel operates, for the most part, as we did when we were a start up. While there is some interleaving within the company and some "larger company" policies and issues we deal with, we are very much free to work as we do, and enjoy the approach that works for us.

Finally, any company either sinks or swims based on the caliber of its people, and I genuinely like and appreciate the people that work here. We are an eclectic, varied, and sometimes silly lot. A propensity for silliness helps when you watch, track and discuss television programming, and that same propensity for silliness will go a long way towards helping anyone who wants to work here interact well with the various players. Make no mistake, silliness or no, while we don't take ourselves too seriously, we take our work and our efforts very seriously.

Sidereel is fun, it's challenging, it makes you think, it makes you laugh, it can sometimes make you exasperated, but overall it's a charge to work here and to learn from my team mates and help others learn in the process. If a dynamic, not stuffy environment, slightly manic pace, mixed with fun and good people sounds like something you'd like to know more about, please reply and I'll see what I can do to help make that happen.

Book Review: ATDD By Example

ATDD is a relatively hot topic that has been getting more and more coverage both in the press and the blogosphere. I also have the benefit of knowing and have collaborated with the author of "ATDD By Example" over the past few years, so I could make this the shortest book review ever and just say "Markus Gärtner is my bud, he's awesome, his book is awesome, so go buy his book!" For those of you out there who suffer from "TL;DR", there ya' go, easy as that.

For the rest of you, you want to know what I really think, and I'm going to tell you what I really think. ATDD is a neat subject, it is a theoretical thing of beauty when it's explained at its simplest level, but what is it truly, and how does it work in a practical sense? Does it work in a practical sense? How can an everyday average tester involved in everyday testing work with this? And do I have to know Cucumber, RSpec and Ruby to have this book be worthwhile?

First and foremost, Markus explains the structure and the goals of ATDD very well. He brings his own experiences and makes examples based on things that exist in the real world, and while the examples are simple applications, generally speaking, they have enough meat to show how they actually work and demonstrate realistic issues that real developers and testers will actually face while trying to use ATDD.

Part I lets the tester follow along as Markus steps through a sample application. Many testers will chuckle when they see exactly what application he chooses; it's famous among the Weekend Testing crowd in particular; ParkCalc!!! He takes us through a very real and applicable workshop style approach, where testers, developers and the product owner determine the requirements, implement the requirements, and then create the tests, using Cucumber and Ruby for this first example. We see first steps, mistakes made, refactoring, and expansion of the application and requirements as we learn more and understand more of the domain, plus ways that we can recognize areas that we can reuse.

Part II takes us through a more elaborate example, testing the traffic light rules in Germany, this time using Java and FitNesse. By taking two different approaches and two different development environments, Markus makes the book relevant to multiple audiences, so that, instead of focusing on the tooling and the language, the reader focuses on the practices and methods used to make ATDD work.

Part III focuses on a number of topics that can help the everyday tester, developer or project manager get more out of ATDD. By stepping away from the tooling approaches of the previous two sections, Markus helps answer questions and deal with issues that are universal. Starting with developing examples to help drive the development process, as well as how to use them, format them and leverage them using pairwise testing, domain testing and boundaries, collaborating with the development team and providing testing acumen and input, making our automation as a literal analog of the requirements and specifications. In addition, taking the time to separate as much of the test details from the data that drives those tests (variables, keywords, etc.) can help make the tests we develop more robust, capable and long-lived.

Three appendices are provided, each covering basic details of three common ATDD testing frameworks; Cucumber, FitNesse, and Robot Framework. The reader will need to reference other documentation to maximize the use of these tools, but each Appendix will get the user in question up and running with the basics of all three approaches.

Beyond the examples, the main point that everyday testers will come away from this book knowing is that Acceptance Test Driven Development is Software Development, and they play a critical part in that process. If they do any type of test automation, they are developing software, and they should use the same practices, methods and methodologies that software developers use. Even if you are not specifically a coder, or you consider your skill set rudimentary, there is a lot to consider here that will help you get closer to understanding the development process and how you can contribute to it in your role as a tester.

ATDD by Example is a book that reward repeated reading. It's likely that you will get one message the first time through, and after practicing with the examples for awhile, you will give it a second pass and pick up many new things you didn't catch the first time. In short, ATDD by Example is a book that you will likely refer to on a regular basis until you get the concepts hard wired. Even then, there will be a lot of interesting tidbits that you will probably catch on as you read through it several times. Barring that, if you'd like to be more "quick on the uptake", then make sure to read Part III a few times, as it encapsulates much of the philosophy and methods that will be the most helpful to testers and developers looking to implement this approach.

Again, I could have saved you a lot of time by having you just read the first paragraph, but hey, now you know why I said it.