TESTHEAD gets a spot in “The Cost of Testing”

Remember how I said I had a few things in the works that I'd feel I need to keep mum about until something more substantial comes of it? Well, with this week's TWiST podcast, it will be as official as it can be, so I figure I can say something now…

I'm going to be part of a book!

 Actually, I'm a chapter contributor, along with about 20 other software test practitioners, some with very familiar names if you read this blog frequently or read the sidebar blog roll I have :). The book in question is dedicated to the topic of "Reducing the Cost of Testing" and looking at avenues that are not normally considered (in other words, this is not a book about outsourcing).

I had the opportunity to participate as a peer reviewer for this project, and during that process, it was determined that a contributor couldn't meet their original commitment. This left chapters not spoken for. As I had been mulling over an idea, I decided to see if I could write and submit a chapter. After some back and forth on the general idea and a few days of thinking about it and pounding a first draft together, I received confirmation that my chapter would be accepted. One faxed Contributor Agreement form later, and it looks like I'm in!

So what did I write? Well, y'all will just have to wait until the book comes out (which we are projecting to be sometime in the Spring of 2011). I can tell you that I focused on something that is near and dear to me as a topic, and that I wrote about it in a way that was personal and not at all academic. Well, not anymore, at least. My first proposal was in my best College Essay format, and decidedly unlike my blog style. The first reply back basically said "yeah, you know how you write for your blog? And how you decided that you would write in a more "book oriented" passive voice format for this project? Yeah, not such a good idea; lose the passive voice, it will make for a better and more personal read". With that, I decided to go back and re-write my first draft and "write the way I talk", i.e. the way I do here; first person, from my own experiences, and with my own history as a guide. It seems to have worked :).

Anyway, I am excited about this opportunity, and hope I get more chances to put my words into print in the future. They say the first cut is the deepest, and if you can survive that, you can certainly do it again. I had no idea how challenging it would be to do this. Not the writing part per se, which certainly had its own set of challenges, but the screwing up the courage to say "come on, you can do this!" and actually submit it for consideration. My own resistance was the biggest hurdle to overcome… and I had every doubt imaginable. What if they don't like it? What if I'm not good enough to write professionally? Why would my ideas be something worth putting in a book? Every one of these, and a few others thoughts swirled through my head, and ultimately I decided the following:

"If they don't like it, they don't like it. So what?!"

 "If you don't think your writing is good enough to be in a book, then it isn't. It's that simple… but wouldn't you rather find out for sure?"

 "You have over 19 years experience with small and large companies, and you've witnessed situations that saved money and those that didn't. Share your experiences; it's possible others might find them interesting and instructive."

 …and the rest, as they say, may be history. Again, I'm a realist at heart, and I tend not to spend money I don't have, or claim credit for something that hasn't happened yet, but this is looking more and more like it will be a reality, and when it becomes reality, I'll be in it. Needless to say, I'll be excited to see this in print!

Weekend Testers: Some Thoughts On Dates

My thanks to the Weekend Testers Europe group that took the time to discuss a mind-blower of a problem today.

Here's the scenario: You have a product that a customer is interested in. This customer happens to be in Nepal. As you are going through the requirements, they state that it will be important that any dates also correspond to the Nepalese calendar, and that those date conversions are handled correctly.

Seems simple enough right? Just make sure that the dates used correspond to the dates in the Nepali calendar. What's the big deal?

It turns out... a lot (LOL!).

For starters, I came face to face with a bias... a Western bias. I have experience on a daily basis with only one calendaring system, that of the Gregorian calendar. It is pretty straightforward; well, except for that pesky leap year deal that makes February so entertaining every four years, but not exactly. See, it's not actually that easy. It turns out that, if a year is divisible by 400, then it's a leap year, but if a year is divisible by 100 but not by 400, then it's not a leap year (2000 was a leap year, 2100 will not be), but if a year is divisible by 4, and not affected by the previous rules, then it is a leap year, and every other year not associated with the aforementioned rules is not a leap year. Got that? Not too bone-wrenching a situation to handle; three if statements in a function and the number of days in a given year, and how many days in February that year is pretty straightforward.

Now, how would you like to know that the days of a given month could vary by a day or two one direction or the other, and a committee met fairly regularly  to determine where and when the days will be each year (or to be closer to accurate, each decade) and the basic rules from the past were applied, but there was no guarantee that those days would replicate? Welcome to the Nepali calendar, which is based on the Hindu Bikram Samwat calendar. This calendar is a "lunar-solar" calendar, which means that keeping it in sync with the lunar cycles is just as important as is keeping it in sync with the solar cycles. This makes for a much more dynamic calendar, with many more rules as to how many days each month has and when they are applied.

This was the testing question we were all faced with today, and the comments in the exchange ranged from philosophical to downright comical. Everything from "well, that makes for an interesting challenge" to "aww, come on! Are you freakin' kidding me?!" (well, OK, that last one was not actually said, but you better believe I sure thought about saying it (LOL!) ).

We discussed a number of conversion programs that were available, both commercially and out on the web, and we determined that, actually, there was no way to test this problem with 100% accuracy. With the Gregorian calendar, we can look to December 31, 3999, and determine that it will be a Friday. With the Bikram Samwat/Nepalese calendar, we cannot do that (well, we might get close, but there is no way to, with 100% accuracy, state that). While the dates are somewhat in line with historic patterns, and if looking at enough data points, we can see that the Bikram Sawat calendar is actually fairly regular, there are just enough outliers to make it nearly impossible to make a nice, clean predictive leap year algorithm like we can with the Gregorian calendar. In the example we looked at, the function actually had each year mapped out with the lengths of each of the months.

We had a great discussion about the vagaries of this system, and we ultimately realized that, indeed, there was no way to test this system to give a 100% accurate answer. We could use a predictive heuristic of past trends, and we could get close to what we thought the dates would be, but we had no way of ensuring that those dates would be accurate. Instead, we decided that, to effectively test these scenarios, we would have to work with past data and with a greatly scaled back range of future dates, i.e. those dates that the astrological committee had determined would be used for the calendars over the next ten years. With that, we determined that we could test, with a high degree of confidence and accuracy, any date conversions performed. Outside of that range, however, and our confidence dropped. A century or more outside of the range, and we felt we had little to no confidence we'd be able to convert to an accurate date.

The lesson from this was not so much the situation of converting dates, but that of wrapping our heads around vague problems, and realizing that what might seem simple on the surface may turn out to be anything but simple later on. We as testers need to be asking questions about our product, about our customers, and their expectations. A person using a calendar product in the West with the Gregorian system would be outraged if we couldn't predict accurate dates within the next 30 years (think of all those fixed rate mortgages and when their loan periods would end for the purpose of calculating interest?). By contrast, due to the vague nature of the way dates are assigned in the Bikram Samwat/Nepalese calendar, the ability to deal with the vague nature of future dates may be acceptable (and may actually be expected). We determined that as long as the agreement and requirements were in sync with the known and determined dates for the next decade, or those determined in advance by the astrological committee that determined the calendar, that that would be good enough.

If these questions intrigue you, and if you find these ideas and the thought of talking out problems like this to b e your idea of fun, then Weekend Testers needs you, and you need Weekend Testers. This is only my third experience with them, and already I have found this group and its weekly meeting and mission to be a "don't miss" opportunity (I actually am a little bummed that I will be missing it next week, but I will be camping with my daughters well away from any Internet connections, and I'll just have to learn to live with that (LOL!)). I do however plan to be there for future installments when I am able, and yes, I'm encouraging others to do the same. It's a no pressure way to learn some new ideas and techniques, and, in this case, address a problem and a challenge I never thought I'd face. whether I ever do again or not is one thing, but the additional ideas and thoughts that came from it proved to definitely be worth the time.

TWiST #9 – Twist Goes to Sweden!

Here's the latest installment!



This week Matt travels to Sweden (well, OK, Skypes to Sweden) to talk with
Henrik Andersson ( @henkeandersson ), a managing consultant with House of Test.


It's been a goal to get a diverse and wide ranging view of testing, and to that effect, we've been scheduling interviews with testers all over the world, hence our sojourn in Sweden this time. Matt talks with Henrik about how he became a tester, his experience working in embedded/regulated testing, some of his consulting experiences and how he is helping organizations move to more exploratory, lightweight methods.

Anyway, for those who want to check it out, here is Episode #9.



Standard Disclaimer:
The podcast is free for 30 days, but you have to be a basic member to access it. After 30 days, you have to have a Pro Membership to access it, so either head on over quickly (depending on when you see this) or consider upgrading to a Pro membership so that you can get to these whenever you want to :). Plus you can also get access to the entire archive of Software Test and Quality Assurance Magazine, and its issues under its former name, Software Test and Performance. Such a deal :)!

A Little TWiST Tech!

TWiST #9 is in the bag, and we are just waiting for it to be posted (looks like we are going to be going with a Friday morning posting; at least that's been the standard the last few weeks). Having done a few of these, I thought it might be kinda' fun to introduce you to the side of podcasting that's not often seen, the technical side.

Podcasts can vary radically in form and flavor. Some podcasts are absolutely bone-simple. Rex Black's podcasts are really just him and a microphone; no production, no post editing (or very little); what you hear is how it happened and what you hear is what you get. Note, I mean absolutely no disrespect whatsoever by that; Rex provides solid information in his podcasts and they are very focused. They also happen to be some of my favorite "repeat listen" technical podcasts. On the opposite end of the spectrum is the production value put into shows like Scott Hanselman's "Hanselminutes" and Dan Carlin's "Common Sense" and "Hardcore History". Truth be told, I look to these two as somewhat of the "gold standard" when it comes to podcasting, and they are the ones that I want to try to model the TWiST podcast after (at least as far as production values; I think if TWiST started talking about Ancient Rome or Neo-Prudentism, we'd lose a few of you (LOL!) ).

So what does it take to produce a podcast? A month ago, I would not have been able to answer that question. Now, however, I have some ideas and some enhancements that are being worked in to make the job a little easier and move faster, so with that...

1. Subjects: Matt pretty much takes care of the real content of the shows. He determines who he is going to interview and then sets up the calls/interviews.
2. Clean Recordings: Again, most of this right now is in Matt's domain. I don't do too much with this. Matt sets up the initial recording, makes the call, and captures the conversation. Sometimes he works with an in-person interview (as was the case with Selena Delasie), but most of the time it's a scheduled call via Skype with the participant. Both are compiled into an audio file and the audio file is posted to a site for massaging and review.
3. A trusty PC with good audio editing software: yeah, I know, there are a lot of awesome and amazing programs that are available for the Mac, but I've been a contrarian just about my entire adult life… I've used a PC for music production ever since I made my first software sequencer nearly 20 years ago, and deliberately did it with a PC, so I've stubbornly kept at it. Today, the choices for doing quality audio for PC are staggering, and the really cool thing is how many options are totally free. For me, the editing tool of choice is Audacity.
4. An "Audio Bed", which basically means a structure for creating podcast formats and the ability to fly-in audio pieces. I do this so that the show has a predictable structure, and also so that I can time elements in the podcast.
5. "Bumps" or audio pieces that allow the show to have transitions, to cue when the show is about to end, or to allow for a message to be inserted when it might be relevant.

A Matt and I have experimented with the show, we have discovered some interesting things, some of which are items that I deal with on the technical "after the fact" end. The biggest challenge is that the volume of the participants can vary. As an example, when I did a level check on the participants on one call, the volume levels were all over the map, even though during the call we all sounded like we were at the same level. Short of having a control booth with everyone's call being routed to a different channel in a mixing board, this is something that I handle post production, where I go in and separate the audio into different tracks, scrub the tracks for audio artifacts where possible, and then level the volumes so that they are close to even.

Another issue that varies with those being interviewed is the challenge of preserving speech and dialogue "ticks", or smoothing them out to have the flow sound more professional. I tend to delete the obvious "um's" and "ah's", especially when there's dead air surrounding them, but some shows go beyond that and cut when people stutter or stammer words. I draw a line between doing editing for format's sake and doing a total clean-up to where the person in question has all of their personality ripped out. As for me, I rarely um or ah, but I do stammer and repeat at times. If it's distracting, I'll edit it out, but if it's just part of the delivery and feels natural, I'll often leave little things like that in (again, it helps show the personality of the subject).

One of the recent experiments that we have been looking at is the 'forum" or "multi-call-in" podcast, where many people are on the same call. This has it's own challenges, because everyone is sharing the same pipe for bandwidth, and the more people are on the call, the more sonic artifacts get introduced. Some of these can be cleaned, but the more people on the line, the fewer "dead" gaps there are that this can be applied. We recently discovered that there was a "slap back" effect when people on calls were not using headsets, but using their audio speakers to listen in on the calls. That can be a real challenge to "clean" because, again, the best place to make those mods is in the dead space, and those echoes and pops take up not just the dead space, but the live conversation as well.

From a testing perspective, one of the things I love about doing this is that I constantly have to learn new techniques to gain an efficiency or speed up the process. There's an absolute deadline; the podcast has to be posted at a particular time (well, OK it doesn't have to be; I'm sure if STP wanted to move it, they certainly could :) ), but it helps me to know that I have a limited time to do any tweaks or make any show development changes or create process notes. That means each week I get a chance to try something to see if it will help or hinder the process. Those things that improve the process, I take notes on and continue to do. Those that don't, I also take notes on and tend to avoid. What's really helpful (and sometimes stressful) is that there's a hard sense of the time requirement for each episode, so I can't dilly too long on getting things "perfect", but I can learn how to get closer to that point for the next episode.

So there you go, a glimpse into my current world of podcast production. I'm still a bit of a greenhorn with this, but the good news is, I'm getting better each week (well, I think I am; in any event… "if you have a different opinion, I'd love to hear it ;)!"). Oh and don't worry, we're not going to be asking for "a buck a show", and thankfully, I don't get sick all that often* (LOL!).




\* This comes from the podcast "Common Sense With Dan Carlin"… his producer is always referred to as the "alleged producer Ben" who may exist (or may not ;) ), and is a running gag in each of the shows with their middle bump being the "Ben is Sick" routine, where they make their pitch for "a buck a show". Actually, some of the time, the things Dan comes up with are pretty funny, and many times the "Ben is Sick" bit can eclipse the rest of the show (LOL!).

Wednesday Book Review: Lessons Learned in Software Testing

It's funny, I've had this book on my short list for a long time, but for some reason never got around to reading it. It was always one of those "yeah, I need to get that one and read it" but other books came and went, and I kept putting this one on the back burner. I think part of the reason is that, when I got involved with the Association for Software Testing and participated in their classes, both as a student and as an instructor, I felt it would better to get some distance from this book until I got my bearings in the class. Of course, my concern was that I wouldn't be able to give a fully objective review after knowing I was effectively teaching the very structure and mission of this book whenever I help teach the Black Box Software Testing Foundations class (or at least that particular component of it). Nevertheless, I will be impartial, honest and fair-headed about giving a truly un-biased review.

 I LOVE THIS BOOK!!! …and Cem Kaner, James Bach and Brett Pettichord did not pay me anything to say that.

 OK, with that out of the way…

 If there was ever a book that could lay the claim to being the "Software Testing Bathroom Reader", this is most definitely it. The book is organized into various chapters and each chapter has a number of individual lessons related to the topic chapter. Each item is meant to be looked at as a standalone area to ponder, and not rush through as though simply reading each chapter. What I like best about this book is the fact that the reader can skip around to whatever section they want to ponder on, and there are likely several lessons that directly impact what they might need to consider.

 This is not a "How-To" book per se. Rather, it is a collection of ideas that the authors have personally gone through and used. Many of the titles of the chapters and many of the ideas and lessons focus on the idea of context in testing. One lesson can counter-act and discredit another, simply because different situations require different approaches.
Each chapter has nuggets of wisdom relevant to its scope. Some of the lessons are brief, and some are more in-depth. The book's sibtitle is "A Context-Driven Approach" and that particular testing philosophy in seen on every page. For some, the lack of "absolutes" will be possibly frustrating, but again, I like the combination of well thought out commentary and personal experience and the recognition and understanding that, yes, in some cases you will need to do B instead of A. What's more, there are lessons where the footnotes will showcase contradictory views, proving the point that many of the methods described may work but they just as likely in some cases not. Som may find that hypocritical and double-speaking. I call that reality and accept that, at times, that is exactly what happens in testing projects.
Below is the list of chapters included:


Chapter 1. The Role of the Tester
Chapter 2. Thinking Like a Tester
Chapter 3. Testing Techniques
Chapter 4. Bug Advocacy
Chapter 5. Automating Testing
Chapter 6. Documenting Testing
Chapter 7. Interacting with Programmers
Chapter 8. Managing the Testing Project
Chapter 9. Managing the Testing Group
Chapter 10. Your Career in Software Testing
Chapter 11. Planning the Testing Strategy
[Appendix] The Context-Driven Approach to Software Testing 


In addition, there is an extensive bibliography at the end of the book, and several of the lessons include the relevant reading areas right along with the text. The bibliography alone, as far as the possible jumping off that can be accomplished and new subjects explored, is worth checking the book out of the library for. Actually reading through and "pondering" each of the topics, however, will yield the true value of this book. Some may find this comparison strange, but I think it's very apropos; "Lessons Learned" is like Scripture (put down the pitchforks, people, I'm not saying it *is* Scripture). How can I make that comparison? Just like Scriptural texts, they can be read multiple times and a different lesson is learned each time, even when you are reading the same words. Does the book morph and change? No, but your own experiences do, and at different stages of a project, or a career, or an initiative, certain lessons are going to be directly relevant and others are not. Reading "Lessons Learned" like a linear book will be of limited use, but find yourself in a situation where you are looking at a specific issue and have specific questions, it's a good bet you'll find a method or an approach somewhere in the nearly 300 lessons listed in the book.


Bottom Line:
I'm already a fan boy of the authors of this book. I consider myself an advocate for the context-driven school of testing, and actually spend my time learning and teaching others many of the ideas espoused in this book. On that basis alone, I find it tremendously valuable, but even if I didn't, I would still recommend it for the fact that it is filled with practical wisdom and little to no sales pitch. It's also nice to see just how relevant the areas in this book are almost ten years after it was published. While some new techniques have been developed and have moved onto the center stage, many of the ideas in this book remain today as excellent strategies to test and improve one's testing methods. Not everything will be relevant immediately, and the reader may have to choose which areas and which lessons are relevant for that immediate point in time. For those looking for the "one true way", this isn't the title for you. For those who realize there is no such thing as "one true way" in software testing, but lots of potentially good ways depending on what the project and process needs, you'll find a good friend in this book. Like Testing Computer Software, I can see myself turning to this book ten years from now for fresh insights, and I'm willing to bet I will get them then as well.

European Weekend Testers: Revisited

Last week I talked about my experiences and the unique opportunity it was for me to participate with Markus Gaertner, Anna Baik and other testers in Europe and participate in the Weekend Testers movement. I had a chance to get back in and do it again on Saturday, and I have to say it's been seriously fun to get to know the participants and wrap my head around new challenges, try out new applications and tools and otherwise just make time to play and learn.

EWT takes place in the afternoon GMT, which means those of us stateside that want to participate need to be up and ready to go by 8:30 AM if you are on the West Coast, or 1:30 AM if you are on the East coast (and you can figure out the in between on your own, I'm sure :) ).

This past week we had a chance to evaluate and pair test a peering application called Mikogo, and we used a simply designed web game as the application to do it. The setup is fairly simple. One person installs Mikogo on their system, then launches the application and invites another user to check out their system. The game app was just a simple web game application that dropped bouncing balls and each bounce played a musical note. By drawing lines on the browser screen, a user could influence where the balls dropped (and with enough creativity, it was possible to make the balls perpetually bounce in an enclosed space. The application itself was of peripheral interest (though we were encouraged to see if we could find issues with the game, too). The real target was Mikogo itself, to see how it behaved in a number of circumstances, and with users spread throughout the world (my pairing partner for this exercise was in India).

After a brief session of testing, we followed with a discussion of what we found, our impressions of the tool and shared some testing techniques and ideas. It was also brought to our attention that WTANZ (Weekend Testers Australia New Zealand) group was going to be getting together later that evening (it would be 11:30 PM my time). Since they were picking up from where they left off the week before, I decided that I'd wait to jump in on a WTANZ event, but there's always this coming weekend :).

Seriously, for those out there who want a chance to practice a little of what you preach (or just want to have an excuse to hang out and talk to a few testers on a Saturday) come out and join us. I think you may well find it time well spent (after my second visit, I'm certainly finding it to be).

Helping the Testing World TWiST

Remember a few posts back I said I had a few things in the works that I didn't want to talk about until I was sure that they would come to fruition? Well, I think enough time and experience has passed that I can now talk about at least one of them (one time is an experiment, two times is a repeat offense, three or more times is a habit and maybe worth talking about (LOL!) ).

There's a weekly podcast now being developed for Software Test Professionals, the organization that was once Software Test and Performance magazine. Recently, ST&P rebranded, renamed their magazine Software Test and Quality Assurance, and set out to have a different mission, one that was more social media like and more engaged with its everyday readers and the population of software testers and developers. It was three years ago that I first discovered Software Test and Performance magazine, and it was also when I first read articles from people with names like James Bach, Jonathan Bach, Scott Barber, Elfriede Dustin, Michael Bolton, and the writer/contributor I have had the most direct contact with, Matt Heusser.

About a month ago, Matt made a request on Twitter to help him produce and support a new Podcast initiative he had started called "This Week in Software Testing" also known as "TWiST". Being a fan of podcasting and always curious as to how they are produced and distributed, I replied that I'd be interested in being involved. I helped craft a structure for Episode 6 (an interview at CAST 2010 between Matt and Selena Delesie). That led to my doing Episode 7 with Johnathan Kohl (albeit in a little more harried state, as I was up at scout camp while producing this one... *that* was an interesting experience (LOL!) ). In between my start on working with this, two other testers, Thomas Ponnet in the UK and Fareed Vaswani in New Zealand have also stepped in to assist, so we have created this interesting loose federation of audio editing geeks who enjoy testing and enjoy bringing this weekly interview show to interested listeners.

A Little about TWiST and the SoftwareTestPro.com model. STP has three tiers of membership. there's the basic level, which is free, the Pro level, which costs $100 a year and comes with certain perks, and a Forum membership, which costs $4800 per year, and includes a free conference pass and other benefits that, frankly are out of my price range for the time being :). Be that as it may, the Podcast has been developed to be available for free the first 30 days after being aired. Archives older than 30 days are only available to those with Pro memberships. To that end, I will post when each episode goes up, a little synopsis about the show, and any other bits anyone may want to know.

Typically the shows are posted on Thursday's, but there can be variations in the schedule. The Podcast for this week is TWiST #8, and features Anne-Marie Charrett, a test consultant in Dublin, Ireland (and featured in my blog roll as Maverick Tester; she was also one of the Assistant Instructors in the AST BBST Foundations class I took in May, which is something I am now doing as well :) ). Matt hosts the show and conducts the interviews. I, Thomas and Fareed work with the audio and help to produce the final product. As of now, I am the one that constructs the flow of the show, creates audio beds, and currently serve as the show anouncer, too.

So for those who are interested in testing topics with a diverse population of testers, we hope you will give a listen to TWiST. We hope you enjoy them, as we are enjoying making them :).

Wednesday Book Review: Who Killed Homer?

Through the years, I have come across a number of books that I have used and valued. These may be new books, or they may be older ones. Each Wednesday, I will review a book that I personally feel would be worthwhile to testers.


This is a bit of a departure, but I found it to be fascinating and, actually, to have a lot to do with the testing profession, more so than I anticipated when I first picked it up as a vague interest in why Classical education was on the decline and what that might mean. "Who Killed Homer?" By Victor Davis Hanson and John Heath, was a book I picked up, not because I'm in any way a Classicist, but because I'm a fan of the Classics (having been turned on to that distinction by Dan Carlin). I never had a true Liberal Classic education (in fact, I don't think most people have in the last 75 years at this stage), but I've always been fascinated by the Greek and Roman heritage and the development of the hallmarks of Western Civilization, both the good parts and the bad. I've also been curious about what made a classical education the hallmark of a truly educated person over the centuries, the knowledge of Greek and Latin, the ability to read Homer, Aeschylus, Xenophon, Virgil and Ovid in their original vernacular, the study of the trivium and the quadrivium… realize that none of these is part of my everyday experience (I can recognize a few words in Greek and Latin and follow the gist, but I'm laughably far away from having even a child's grasp of either language for extended reading). Nevertheless, I'm nerdy enough to enjoy the Iliad and Odyssey, Aeneid, Trojan Women and Lysistrata, and I have a great fascination with and a genuine joy in knowing about and reading about the Hellenic and Roman cultures that developed, and how they morphed together and helped to shape Western Culture today.

 OK, yeah, that's great and all, but what does that have to do with testing? A lot, I think.


Chapter 1: Homer is Dead
Hansen and Heath are Classicists. They are true believers, and this rings out clearly. These are not dispassionate and theoretical wonks, but people who truly love the craft, history and passion that came out of Greece, and how that civil order and world view, both brilliant and dark, both beneficent and monstrous, had a huge hand in developing the world view of the West (the West in this case meaning the Greco-Roman West, and ultimately the Christianized West, basically everything from Central Europe to Spain, Portugal, the U.K, and their offshoots like the U.S., Canada, Latin America, Australia, etc.). In this world view, Homer and the classics of antiquity were seen as vital to the development of the human mind, the study of the literature, sciences, philosophy, ethics, geography and history all worked together to help create an inductive body to help reason and work through challenging issues, and develop a mind and body of understanding that allowed anyone who studied it to have the tools to reason through and learn any discipline. Hanson and Heath make the case that we have lost that, and that the college curriculum and the classicist professors themselves are ultimately to blame for its loss.

Chapter 2: Thinking Like a Greek
Hansen and Heath break down the attributes that they see as being inherently Greek and Western, such as an ability to see man as being made in God's image (or God in man's image, depending on the particular writer), that the polis, or people, were the pre-eminent institution, that three classes instead of two was vital for civic development, that yeomen with an equal responsibility for their fields, their homes, their political seats and their armed forces was essential (the Greek Hoplite owned his own land, hoed his owned fields, passed laws in his assembly, and work his own armor out to fight wars with his other fellows), the ability to write and create philosophy separate from government and religious interference), to reason and come up with solutions based on data and empirical evidence, not just the whims of a ruler or a priest, and a version of equality and egalitarianism that first starts in Greece (not a perfect egalitarianism, women and slaves certainly would disagree) but much closer to our current world view than any other culture of their time. Hanson and Heath show that many of the hallmarks and attributes we take for granted in such things as political discourse, law, public relations and community first appear in the Greek world, and develop and spread through the Latin age.


Chapter 3: Who Killed Homer…and Why?
Here's where Hansen and Heath draw their daggers and go in for the kill… they say it's an inside job, and that colleges and academia is the murderer. This is the section that I think testers will find to be very interesting. Why do I say that? Because so much of the infighting described reminds me of the testing wars that we are currently seeing today. I could easily transpose much of this text, and remove the name Homer and replace it with Deming or Kaner (sorry, Cem, I know you are not dead, and certainly hope you will not be for a long time :) ). We would do well to heed the warning this chapter tells of, otherwise, we might well see sometime in the future the warnings of "testing education is dead" and that would be a shame, because I think it's just now, finally, starting to get a true breath of sustaining life.


Chapter 4: Teaching Greek Is Not Easy
This chapter goes into the challenges that Classicists face, and I must admit, it was a daunting chapter, and yet, it felt familiar, in the sense that it could just as easily replaced all of the terminology of Greek syntax with the terminology of Automation, or of Combinatory and Orthogonal methods, ET and RST or any other testing discipline we hope to see others learn. Perhaps the challenge we now face with testing and its true growth and development is the fact that we are realizing that testing is hard work, when it is done correctly, and it is the passionate few that really drive that learning along… how many of our profession get along and just do what they do without ever seeking out new ideas or new understanding, or even looking to the past to see what has come before? I know from my own experiences that the numbers are higher than we want to admit, and we're a young discipline all told.

Chapter 5: What We Could Do
Hansen and Heath create a broad and prescriptive approach that they feel would help cure the declining and ailing world of Classical education. They said in 1998 that it's not too late, but it is definitely on life support. It's interesting to note that the prescriptive suggestions that they made have not, to date, been applied, but they definitely remind me a lot of what we are seeing happening in the world of testing education (and some of the infighting) today. Do we care more about certifications and accolades than we do about competency and effectiveness? Do we care more about speaking engagements and conferences and personal aggrandizement than we do in perfecting our craft and creating an environment where people actually learn? Do we sit comfortable in the ideas that we have our standards and our best practices, or do we shake up the system and really go to find better ways, always, to improve and develop our people?
The book ends with an appendix of suggested readings, ten titles from the ancient Greeks and ten titles about the ancient Greeks, with commentary about why they have value and what they can teach us about the Greeks then and ourselves today.

Bottom Line:
It may be fairly said that likening "Who Killed Homer?" to the state of testing education and practice is a bit of a stretch, and yes, I can also say that there is much about classic education that may not turn a lot of people on (and for that matter, there's a large population that's probably not all that enthusiastic about Greece and Rome to begin with, or Western Civilization, at that. Be that as it may, there's much to find interesting and intriguing in this book, and if you play the mental game of replacing "Classics" with "Testing", a lot of relevancies pop out at you, in my opinion. Again, I come from this not as a classicist, but as a fan of the classics. There was much to promote thought and reflection on what has become of classical education, and it is my desire to not see the same thing happen to our developing testing educations that I suggest giving Who Killed Homer?" a read. If nothing else, it's neat to see those passionate about their endeavor make the case to try to save it. For those who are striving to see testing education gain a foothold in our Universities, this book makes the case for what we may wish to never have happen to our discipline.

My First Experience with European Weekend Testers

As I have lamented in the past, there is a real challenge when you work as an "Army of One". The biggest factor is the oft feeling of isolation and lack of interaction. It can be frustrating to go through each work day knowing that you are responsible for all testing, all interaction with the other groups, all reporting of issues. Who is there to tell you that you might be able to look at something in a different way? Who is there to give you advice and suggestions when you are frustrated, who is there to give you a set of fresh perspectives to consider?

For the Army of One, the answer usually is "no one". We are left to our own wits, to our own instincts, and to our own judgment. Often that is fine; we are well versed in the techniques and methods to determine how we will test a given situation… but wouldn't it be great to just step back, breathe deep, and reach out to others who might have similar issues and challenges, or may have potential answers to those challenges? Well, if you live in Europe (or are willing to sync to European hours) you do have a way to reach out to others, and actually practice the test methods and ideas that you have, and possibly learn others. Let me introduce you to Weekend Testers!

Weekend Testers actually started in India. Pradeep Soundararajan gets the credit for starting the first chapter, and the idea has spread, first throughout India, and now into Europe. It's a decidedly simple one; give users access to an environment via Skype, a puzzle to examine (sometimes an application, sometimes something unrelated to software), a way to pair up with other testers, and then discuss the issues you found (or didn't find) and the techniques you used (or wished you could use).This activity has spread to Australia and New Zealand, and it has also spread to Europe (courtesy of excellent facilitation by Anna Baik and Markus Gartner).

Now, I know the first question you are asking… Yeah, I said it, too. "Why are you having to call/Skype Europe?! To do software testing, of all things!" Actually, my answer is really simple; it's because there isn't a chapter of Weekend Testers in the U.S. at this point in time. Yeah, I was stunned to see that as well. It strikes me as interesting that, with the testing talent that we have here in the Western Hemisphere (yes, I'm looking at you Argentina, Brazil, Canada, Chile, Mexico, the U.S., Venezuela and anyone else I happened to miss :) ), that someone hasn't picked up on this idea and run with it yet. The reasons why or why not are irrelevant, and ultimately, not even entirely necessary, because the European Weekend Testing group is a great bunch of people to get together with.

I joined them for their EWT30 testing session. EWT stands for 'European Weekend Testers" and the 30 stands for, well, the fact that this is the 30^th time they have gathered since their inception. This also helps when you visit the Weekend Testers site and want to see what has happened, what has been discussed, and understand the interesting dynamics at play. I had the chance to join in and work with a group that tested a collaboration application. I was able to step right in, discuss the situation, explore the mission statement of the testing needed, install and try out the application in question, pair with another tester, talk through the features and limitations that we discovered, and comment on the issues in a tracking system. At the end of our allotted testing time, we all gathered together and had a debrief and discussion about what we tested, including traps we fell into, issues that prevented us from achieving our goals, and key things we learned in the process. My partner and I discovered an annoying issue that we fixated on and tried to replicate and get down so we could report it… only to discover that we were so fixated on this particular issue, that we ran out of time to actually test the primary purpose of the testing, which was sharing of applications (Whoops!). The group had a good laugh, and I was able to share that I actually learned something; when we get fixated on little things when we test, we often miss the bigger picture… in this case, the whole point of what we were actually testing!

Each of the test sessions is summarized, and the attendees are listed and the chat sessions are available for review. The interaction is fantastically valuable; I was only there for two hours, and when the session was shutting down, I didn't want to leave! I'm not sure if that speaks to my being starved for tester interaction in my daily work life, or just the fact that this was a good group to keep company with (or perhaps both) but I really enjoyed the time I spent with this group. Scout Camp precluded my attending last Saturday, and Wood Badge will preclude me this weekend, but barring any other commitments, which I'm hoping not to make, I will be there for EWT33 :)!

So to those out there who are feeling a little less than stimulated in your testing lives, who want the opportunity to interact with other testers and learn a thing or two (or five) and get to rub shoulders with both experienced and new testers, all with unique insights… oh and don't mind using some of your morning hours on a Saturday (the EWT30 session was 8:30 AM - 10: 30 AM for me), then I highly recommend that you participate in a Weekend Testing Session. I plan to participate as often as I can, and who knows, if I get enough experience with the paradigm and the method, and find some like minded folks in the Western Hemisphere, perhaps we can create a chapter of our own and help bring up the testing knowledge here as well. Why should Europe and India get to have all the fun :)?

Scout Camp and the Process of Experimentation

For those wondering if I had fallen into a black hole or disappeared, nope, I just went away for a week to be a leader at Scout Camp.every year, my Troop of boys picks a place to go, saves up the money to attend, and then focuses on the challenges and areas they would like to improve, have fun with, and work towards advancement.

This year, we went to a place called Wente Scout Reservation, located in Mendocino County, Northern California. the boys liked this camp after visiting it for the first time last year (it's highlights are a world class equestrian program and a lake that is fed by several hot springs, meaning it is actually warm when you get in (well, on par with a heated public pool at least). Add to that the other program areas like handicraft (or as they like to refer to it this year, "Mandicraft", since all of the counselors for these badges were guys this time around), nature, waterfront, shooting sports, horsemanship, scoutcraft (where all of those knots we learn come into use to build structures like towers and bridges, among other things) and we had a pretty busy week ahead of us.

We were actually fairly late in the process of signing up this year, and so we were placed in the farthest camp area, a place called Sunrise Ridge. It's a gorgeous site for a camp, but it was so far away from almost every program area. I knew there would be complaints, but I wanted to make sure that we had more than just an attitude of "we don't want to walk so much to work with", so I decided to do a little test. First, I decided to see how much time it would take to walk from our camp area to the main gathering place each morning. Using a standard pace, I determined it would take me about 12 minutes to get from the camp site to the gathering area and about 15 minutes to get back. From there, I also determined it would take about 10 minutes to get from the main gathering area to the corral where several of my boys were planning to take the Horsemanship merit badge. With my size as a 6'2" man, I also reasoned that my smaller and younger scouts might require more time, since they don't have as large a stride as I do (but they may also be able to run at a better clip as well, and may be more apt to do so :) ).

Once I had all of the information in hand, I went to the Camp Office and I explained to them that seven of my scouts would be spending an hour each day just walking from their campsite to the corral and back. Would this kill them? Probably not, but it was certainly less efficient a use of their time than if they were located in a camping area closer to the corral. Also, since this was a week that many schools had started, there were fewer campers in attendance, so very few campsites were 100% full. With this information, I simply asked if we could relocate to a site that would be more accessible to the scouts taking the horsemanship badge. They considered it, and saw that it made more sense to have us be moved to a closer spot. Key takeaway: it pays to do a little reconnaissance work before you present a position, because data and an argument based on data is much more effective than just expressing that you have to walk a long way.

Another interesting aspect discovered in camp by a few boys this week was that technique matters. This became especially apparent to two of my boys that were taking the Shotgun Shooting merit badge. This is a challenging badge for most boys, but it's especially challenging for boys who are not very large in stature. Shotguns are heavy, and it's a workout to keep them up and aimed correctly while shooting through a series of rounds to qualify. Two of my boys were having difficulties with qualifying for the badge, and were not sure that they could actually do it. One of our adult leaders in our Troop who grew up shooting shotguns decided to come with them and watch them shoot. as he did, he notices a few things about their stance, their approach to aiming the shotguns, and what was causing them to have trouble hitting the targets (in this case, "clay pigeons" launched from the shooting line). After seeing their technique, my friend, helped them to get a better stance and gave them  a simple suggestion; "plant your cheek so hard against where the barrel and stock met that you get an imprint of the Winchester logo on your face!" This had the effect that it made the boys really focus on their aim, and having their heads in the proper place to aim correctly. Once they did this, they were able to hit the target 5 our of 6 times or better. The boys were able to qualify without difficulty after this. Key takeaway: having someone observe your technique and offer suggestions based on experience can lead to massive improvements in performance.

One of the boys that came with us to camp this year had never had an experience like this, and he had a difficult time keeping himself organized. Many times it was a matter of finding what he needed in a pile of thing in the tent, or working to get from point A to point B in a  timely fashion. It was a challenge to get the rest of us  adult leaders to make sure he was on track and that he was doing what he was supposed to be doing in a  timely manner. One such example was in Basketry. This is considered by many boys to be a "low hanging fruit" badge, one that can be quickly completed at camp and has few requirements. Making three types of baskets and weaving the wicker to make the seat of a camp stool. That's it. Still, this boy had to come home with a partial on his merit badge because he forgot to bring all of the baskets (he had two of the three) along with the camp stool. While we had encouraged him to make sure he had everything together, at the end of the day,  he missed his target and he had to settle for an incomplete. Key takeaway: a little bit of preparation and organization can go a long way towards helping achieve your goal.

One of the most coveted, yet least seriously attempted goals at Scout Camp is to do the Mile Swim. this is because there are many things that have to be accomplished to do it. First, a commitment to wake up early each morning, often when it is still dark. second is to convince a rower and a spotter to come with you each morning as you make the attempt (this is for safety reasons, so that the boy can be pulled into a boat if he gives out) and third, the fact that a large body of water that you cannot even see across in the darkness is waiting for you to get in. One of our scouts decided to try this, and he asked some leaders to assist him, including his dad. thankfully, I wasn't asked to be part of this team (I would have if he asked, but I also sighed in relief when he didn't (LOL!). The Mile Swim is a progressive goal. The first day, you swim only 1/4 mile. the next day, you get there a little earlier and swim 1/2 mile. The third day you get to the lake even earlier and go for the full mile. On this third day, the water was covered with a mist that made visibility difficult, in addition to the fact that it was pitch black outside. At this the boy in question started to freak out and refused to get into the water. Needless to say, this didn't go over well with the rower and the spotters, who had spent the previous two days and this day waking up early to help this boy meet this goal. It took a little bit of encouragement, pressure and finally splashing the boy with lake water to get him to finally slip into the water and start swimming. They also told him "if you give it your all and you can't make it, we can pull you in and you will know you tried your best and couldn't do it, but to not try now, after setting up so many days, is unforgivable!" Once he got into the water and started swimming, then he was able to make the rest of the journey, and yes he completed the Mile Swim! Key Takeaway: usually when we have a goal in sight, it's that last push that will always be the most difficult and discouraging. We need to tell ourselves it's OK to try and fail, but to get discouraged and not try at all is unforgivable.

So here I am, back home, somewhat caught up with life, and looking forward to getting back into the swing of things as relates to work, my kids going back to school, and the challenges and issues that I will face going forward as a tester. I had a week to teach boys to overcome obstacles, to learn, fail, learn again and ultimately succeed. Will I carry those same lessons with me to work this week and in the coming weeks and months? I certainly hope so :).

Wednesday Book Review: How to Have a 48 Hour Day

Through the years, I have come across a number of books that I have used and valued. These may be new books, or they may be older ones. Each Wednesday, I will review a book that I personally feel would be worthwhile to testers.

There have been many books written over the years about "time management" or "self management", ranging from light and fluffy to drill sergeant intense. Don Astlett's 1996 book "How to Have a 48 Hour Day" (and the more recent version of the book which is titled "DONE"; just to make sure everyone is clear that these two titles are the exact same book) is definitely on the latter end of the spectrum. Don is a guy who created a cleaning business and built it up to being a corporation that employs a lot of cleaners and maintenance people. I first bought this book back in 1996 because Don came from a background I also came from (while in school and while I was a musician, I supported myself by cleaning houses and businesses, too). This, however, isn't a book about cleaning (if that does interest you, though, Don has a bunch of books on that topic;  Clutter's Last Stand is one that I can recommend :) ), but a book about making a commitment to do one thing, get more done.


Don makes it clear that his philosophy is a tough one. He believes in the power of producing, and in being consistently and regularly productive, not just in work, but in all areas of life. To some, his tone and attitude will be a turn off, and frankly, I don't embrace everything that he espouses, but there's enough here that I do agree with and appreciate that I come back to this book again and again. One of the key points that Don makes early on in the book is that "[…]we can't stretch time, buy time, save time, stop time, find time and beat time. We are foolish enough to think we can manage time. You don't and won't do any of these and you don't make time either (wow, what a commodity if you could manufacture time and sell it!). We have only one alternative here, there is only one single thing we can do with time and that is use it. We can't manage time but we can manage our own behavior and activities and use it wisely."


Chapter 1: Why Do More?

Don gives a working list of reasons why any of us would want to get more done. Many of these resonate with me: self-respect, being in control of situations, producing and shipping, qualifying for opportunities, for a stronger family, for a sense of accomplishment, for attention, etc. In short, to do more, you first have to have a reason to want to do more. Don spells it out early on, his goal is not necessarily to do more in less time, it's to do more, period. Making a goal to focus on getting more things done will in and of itself help make it possible.



Chapter 2: Ordinary Me, Do More?

Let's face it, we all have, more or less, the same brain structure, with the same number of neurons and dendrites. The difference between being ordinary and extraordinary is a matter of choice and perseverance. Don gives numerous examples of people who come from different walks of life, different situations, and different work experiences, and shows how all of them were able to maximize their opportunities and experiences, whatever those opportunities might be. At the end of a chapter is a list of productivity traits that you can select that may (or may not) describe you, and where you might fall on the productivity curve. Me personally, I could use some help in certain areas at certain times of the day :).



Chapter 3: A Little Subtraction… Adds a Lot of Production

In many ways, the clutter that surrounds us (physical, mental, emotional) can be our greatest enemy when it comes to being productive and focused on completing a goal or task. Taking the time to remove elements that stand in the way can be huge time savers and goal jump starters. Here's where Don's stock and trade comes into play the best. Remember, Don's a cleaning man at heart, and he's very much anti-clutter. His first maxim is to "dejunk". Get rid of items that are distractions, or put them in places where they will not interrupt what you need to do. Likewise, prune before you prioritize. Rather than make a list of priorities, decide which things, at least for the time being can be swept out of the way completely. Make it a point to get the right tools for the job, and maintain those tools, rather than drag around more than you really need. Remove impediments that cause you stress, whatever they may be (financial, physical, emotional, etc.). To paraphrase Albert Einstein, sometimes your biggest break-through's will happen because of break's-with.



Chapter 4: The Mainspring: Direction

When people who have become famous for something (musicians, artists, athletes, politicians, business aficionados, writers, etc.) are asked how they got where they are, it's rare to hear that they made it to where they are by accident. In an overwhelming number of cases, people got where they are because that's where they wanted to be. Likewise, Don makes the case that people tend to be where they are because they've chosen a path to get there, and created a direction to follow. To continue with the clock analogy the dominates the book, Don uses the metaphor of a mainspring that drives a clock to describe the direction that we all need to get where we want to do. Make a point to decide what will excite you, motivate you and get you going towards where you want to be. Very few people need much motivation to go and do things that are genuinely fun (no one has to twist my arm to get me to go snowboarding, for instance). Focus on the end result and where you want to be, rather than all of the effort that will be required to get there. To borrow the old platitude: if you don't know where you are going, all roads will help you get there. If you know where you want to be, and fix your sights on that destination, you'll find a way to get there.



Chapter 5: The Magic of Early

 The biggest enemy to accomplishment, and the biggest creator of stress, at least to me, is being late. It's my biggest pet peeve, and I tend to get irritated with people who are late, but more to the point, I'm even more annoyed when I'm the one who is late. If left to my own devices, I will often procrastinate, and run myself up to the last minute on items. This can at times be very effective, because I get hyper-focused and sometimes I do very good work, but just as often, I end up getting blindsided by something I didn't consider, and the net result is I'm late with my deliverable, whatever it may be. Don makes the case, rather forcefully, that the key to getting more done is committing to being early. That goes for finding problems early, getting involved in projects early, and taking the time necessary up front to avoid getting into last minute scenarios. This is definitely relevant to software testers. How many times have we heard about how inexpensive it is to fix issues found in the design stage as compared to fixing an issue that is discovered in production? Don presents the idea of a front-log in this section, the idea that we should work on things that are ahead of us rather than drag behind us things that we keep meaning to get to when we catch up with everything else. Make a list of the things that you want to do and hack at it every chance you get, so that you finish things before they are due, before a deadline looms, and before the chance of being late ever enters the picture. This is a simple concept, but as many of us know, it's far from easy, especially when others tend to work in the opposite manner. We can't control what others do, but we can control what we do, and working ahead or having a front log puts us in greater control of actually getting the things done that we want to, and we have more to say in that outcome if we are early.



Chapter 6: How About Some Help?

The fact is, few people ever totally "go it alone". When someone has made the decision to go somewhere, do something, or accomplish agoal, usually they get some help along the way. The key is to determine the right kind of help at the right time. Sometimes that help is other people, sometimes its good tools, sometimes it's having spares or duplicate items in different places to help you keep going and sometimes it's just having someone get on your case when you are slacking. In my world, I find I get more done and I accomplish more when I have "accountability partners". They don't necessarily have to be people that are directly related with a project or goal, but they are people I tell what I am doing or hope to do, and often, these people get as excited as I am about achieving the goal, and they help me indirectly by cheering me on, or at times even directly by giving me a hand when I need it. Waiting for a "big break" or that magic moment when everything will "just work" is pointless. You can get a lot of support, some high fives, maybe even a bit of grilling to do what you need to do, but ultimately, even with your helpers, you need to roll up your sleeves and just "get on with it".



Chapter 7: Timepiece Tuners

To continue with the clock metaphor, Don offers some advice to those who want to keep their 48 hour clock on time and tuned up. Small steps like keeping your primary objective in mind, focusing on being effective rather than just being efficient (if you can do both, great, but if it's one of the other, go for effective over efficient), making the point to do what you need to do to maximize your productive time (prepare well, organize well, be early), and avoid the trap of being busy just for the sake of being busy. Lots of time and effort can get chewed up in the busywork we do, but little is there to show for it at the end of the day. Don makes a point about being "mentally awake" when it comes to our work and the things that we do. The best way to describe this is to imagine playing a game of chess. Many players think about their next move when it's their turn, but the truly excellent players think two, three, or four moves ahead. Their success rate in the game is immensely improved because they are looking ahead. Try your best to have everything you need together so you don't have to hunt for what you need or move around needlessly to have what you need to be effective. Learn about when you are at your best physically and mentally, and when you are not, then use the time accordingly. As for me, my "hottest" times of the day are early morning and late afternoon. If I have anything creative to do, the early morning hours and the late afternoon are when my brain is best suited to do those tasks. Late morning/early afternoon and late evening are great for "busywork" tasks, shuffling papers, and anything that doesn't require me to be "fully on". Knowing when to move from one task to another, what Don calls "ship jumping" is also a good skill to develop. If something isn't working at the moment, move on to something else and come back to the other task later.



Chapter 8: The Healthy Stretch (Will It Hurt?)

Sometimes we may feel like we are really doing all that we can do, and that we just can't take on any more. In many cases, this is the absolute truth, and taking on more, or committing to something else will be the proverbial straw that breaks the camel's back. But truth be told, that's rarely the case, and for most of us, adding another obligation or goal doesn't kill us, it energizes us, when it's really something that we want to be doing or feel strongly enough about doing it. Back to my snowboarding example. I could have had a killer week of long days, back to back meetings, crunch time, and any of the other things required, yet Saturday morning at 4:00 AM I'm practically bolting out of bed to go hit the snow. Why? Because it's something I love to do. We rarely find ourselves wallowing in pity when something we're really excited about doing comes into the picture. When we're excited about what we are engaged in, momentum does half our job for us (well, it certainly seems to be that way for me). Sometimes, though, we have to focus on things that are not always so fun, and that actually require us to make that stretch to do what we need to. The same aspects that work for the fun stuff can also come into play here as well. IT may take a little longer to get excited, but when a goal starts gaining momentum, often our own level of excitement about keeping it going builds with it.



Chapter 9: The Harvest of Having a 48-Hour Day (Every Day!)

The last chapter is a summary for why we would want to experience this mythical 48 hour day, really the net benefits of being a high producer and getting things done. For me, the idea of accomplishing a lot of things really comes down to wanting to be engaged, but engaged in a meaningful way. I personally do not want to be the dead weight of any team, to be the one dragging my feet. Sure, it happens, and sure, I'm not at my best on all days (who is?), but there's much to be said about getting into those areas that you want to do well, and rolling up your sleeves and getting elbow deep in the mud and grease. It's work, it's challenging, but it can also be a lot of fun. If you are lucky enough to be able to literally be doing what you love, becoming a high producer, frequent shipper, and a 48 hour watch wearer will be very simple. For some, that may be a really tall order, or perhaps an almost impossible one. Ask yourself, if you don't hove what you are doing, perhaps it's time to put your efforts and energies towards doing what you really want to do. Getting involved in a broader community that shares your interest, your vocation and your passions can do wonders towards getting you into this mindset. The goal of being able to do more is that, ultimately, you'll be one who can enjoy more and have more to show for your efforts. That's the theory, in any event, and overall, I can't say I disagree with it.



Bottom Line



Don is advocating what he feels is a difficult and demanding road, but one he feels is worth it. There's a lot to like about what he advocates, but many will be put off by what they feel is effectively advocacy of being a workaholic. Some of Don's suggestions are a bit extreme, and were some to follow everything he says to the letter, they would likely feel burned out, resentful and unhappy. For me personally, there's a lot to like about what he advocates, and I choose those things that work for me, and I downplay or don't actively use the things that I feel do not or will not work well for me. Ultimately I like his closing line in the book… "what would you do with a 48 hour day? Share more, serve more, lift yourself, be more selfish or unselfish? Once you have more time you could even waste a little time if you wanted – get out of survival into savoring". I've had this book for 14 years now, and I find myself coming back to it again and again. Again, you may not like everything in it, but I'll still say that there's much to appreciate and apply here for just about everyone.




 

Helium Hand Syndrome

I'm not sure if anyone else has this problem, but I figured it was time to say something about it. Part of the reason I haven't been posting as much is that there are a number of things underway that I don't necessarily want to say what I'm doing with them until I've actually done something substantial enough to warrant mentioning them (yeah, say *that* ten times fast (LOL!) ).


What this comes down to is that, I'm a volunteer junkie. A good friend of mine says I suffer from "Helium Hand Syndrome", meaning that, if I'm in a room with a bunch of people, and a project is suggested, somehow my hand will get raised and I will volunteer for it. Seriously, it's part of my DNA, and I do it a lot! Why is that? Does it make any sense to be more interested in volunteering than it does to want to be paid for ones work?


I've struggled with this and I think I've come up with an answer. Granted, this answer is wholly unscientific, and it's also only relevant to me (your mileage will most certainly vary). I think the reason that I volunteer for so many things is that I want to ultimately be involved in something that interests and motivates me, but have the option to walk away from it if I decide I'm done with it. That's my reasoning when I start, at any rate. What actually happens, though, is almost always very different. I think of the projects I've volunteered for that I have actually walked away from, and honestly, I can count them on one hand. Most end on their own (the project or situation is time bound, and when it's finished, that's it, time to move on to something else) but many of them are open-ended. I know that they will take time. I know that there are other things I want to be doing. I know that I'm biting off more than I can chew. Deep down, these are all realities I'm aware of… yet I volunteer, again and again and again. Is there something wrong with me?



Part of me says yes, there is. I'm a glutton for punishment, I take on these projects that interest me and I know full well that they will consume just about every piece of free time that I have. I realize that other things I should be doing are being pushed aside so I can take on these new opportunities and projects. I get less sleep. I interact with some people less frequently. I make myself into a walking zombie at times. It would seem that these would be enough impediments and negatives to get me to swear off volunteering forever.



But there's another side to this, and that's the joy that I get when I know that I'm helping make something happen. The feeling that I've made something that just might last, that I can point to it and say "hey, you see that? That's my handiwork!" I also feel that there is a certain sense of community and communion with others that comes from these opportunities. Truth is, in most cases, the projects themselves, while often interesting and fun, are not the lasting element that sustains me over time. It's the interaction with people, those I'm intimately familiar with and those I only know through email conversations, but a community nonetheless. The projects themselves are stepping stones, interesting things to do at a time, but it's the relationships I develop with the people involved in those projects that mean so much more, a sense of connection with others that goes beyond that particular experience, that brings me back time and time again.



I was reminded of this again last Saturday. I and a number of people were invited to celebrate a special birthday party. Cub Scout Pack 290 in San Bruno celebrated its 50^th year as a chartered organization. I and a few other adults were on hand to be honored for our volunteer service to the organization over the years (for me that was five years as an official and de-facto Den Leader, and three years as Cubmaster). It was great to see the faces of so many adults I'd know over the years, and rubbed shoulders with and gotten my hands dirty with, to see so many boys who had grown up and gone on to other things, but had those memories of those days as Cub Scouts and cherished them. I smiled as I was handed a framed commemorative patch and letter thanking me for my service, and while I appreciated the framed patch, I appreciated the people and relationships that that patch and letter represented even more.



There are some cool things in the works right now that I a m involved in, but forgive me for playing them a little close to the chest until they are closer to being completed. I'd feel like a bit of a cad to talk up something and then not be able to follow through on it, so I'll keep mum for the moment on a few of these (but hopefully not too long ;) ). Just know that I'm excited to be engaged, to be doing so many things with so many great people, both in the testing world and in other areas of my life, and know that the spirit of volunteering will likely always be strong with me, and that those "Helium Hands" will likely rise again.