Friday, September 30, 2011

Sometimes, Design Really Is the Problem

Another fun entry from Aaron Scott's Two Leaf Clover cartoon. Admit it, you've been on projects like this. I think anyone who has ever been involved with testing for longer than a few years has at least one doozy of a story where we go back and ask ourselves "OK, really, what were they thinking?!"

While I don't typically go out of my way to out my companies and the issues over the years, there are a few that were certainly memorable. One of my favorite painful experiences was a 3rd party title that was presented to Konami to publish. I remember this title because it was the very first "game" I ever tested. I will admit the premise seemed interesting. It was very European, a post apocalyptic game with religious overtones and elements, battle of good vs. evil in deep space. What's not to like? After a week, I discovered that there was lots not to like. Clunky levels, really bad AI, and frustrating challenges that, if not played just right, were painfully hard to pass. This was originally a title for PC and Xbox, but it was dropped from the Xbox distribution list and developed just for PC release. That alone should have been fair warning. Judging by how many people we had work this title, and how long it was in testing, I released a sigh as I realized that it was not going to go well in the marketplace, and sure enough, it didn't. This wasn't just an issue with bugs. It wasn't just an issue with story. It was an issue with design flaws throughout the game, to the point that finishing the game was more of an expenditure of tremendous effort than a feeling of any real triumph. More of a feeling of "Glad THAT's over!"

Sometimes design flaws need not be so devastating, and occasionally, they can be found early enough to be corrected before big costs are incurred. When I worked at Synaptics, I got to do more than just test software. I actually got to lok at Environmental factors on physical devices. We're talking real stress tests with weights, fulcrums, freezing temperatures, super hot ovens, and my personal favorite but slightly annoying device, the Electro-Static Discharge (ESD) gun. ESD is a neat black art, and it's actually quite interesting to see what responds to it and how to isolate tests. One of the key early developments at Synaptics was the touch pad that is now ubiquitous on various vendors laptops. Making covers for these capacitance touch pads meant that they had to have surfaces that matched the notebooks they were going to be inserted into. We had a cool bunch of silver pad covers come in, and as I was testing them, we found really strange behavior at around 9,000 volts (that may seem like a lot, until you realize that the human body routinely carries the ability to discharge about 8,500 volts at any given time just through our fingertips). 50,000 volts and strange behavior is understandable. 9,000 volts and strange behavior was definitely odd.

I asked for a chemical makeup list for the sheets of metallic silver covering we were working with, and nothing jumped out at us immediately. It shouldn't be a problem, the metallic silver was being simulated with crushed mica. Mica is a dielectric and an insulator, so why is it behaving strangely when we apply the ESD tests? This prompted some of our engineers to have additional talks with the engineers producing the covering (a 3rd party) and it turns out that there was a higher level of other elements in the mix to make the covering in addition to mica. Not a large amount, but just enough to skew the results of our tests. A few weeks and a reformulated sheeting was ready. We tested it and it didn't have any of the problems. Our Program Managers often joked with me that in that one day I may have justified several times my salary :).

As I posted earlier today in my review of "How to Reduce the Cost of Software Testing", Selena Delesie makes the point in her chapter that we cannot test quality in.  We absolutely cannot test and add quality if there is a fundamental flaw with the design. No matter what we do as testers, we cannot overcome some issues, but we may have a chance to influence a few if we get to them early enough.

BOOK CLUB: How to Reduce the Cost of Software Testing (3/21)

For almost a year now, those who follow this blog have heard me talk about *THE BOOK*. When it will be ready, when it will be available, and who worked on it? This book is special, in that it is an anthology. Each essay could be read by itself, or it could be read in the context of the rest of the book. As a contributor, I think it's a great title and a timely one. The point is, I'm already excited about the book, and I'm excited about the premise and the way it all came together. But outside of all that... what does the book say?

Over the next few weeks, I hope I'll be able to answer that, and to do so I'm going back to the BOOK CLUB format I used last year for "How We Test Software at Microsoft". Note, I'm not going to do a full synopsis of each chapter in depth (hey, that's what the book is for ;) ), but I will give my thoughts as relates to each chapter and area. Each individual chapter will be given its own space and entry. Today's entry deals with Chapter 2.

Chapter 2: The Cost of Quality by Selena Delesie

In Chapter 2, Selena makes the point that Quality is always a cost. Good customer service is a cost, solid marketing materials is a cost. Salaries for hiring excellent developers and testers is a cost. Training, fixing errors, testing (and retesting) and reporting... these are all areas that an organization needs to be on top of their game to deliver quality... and none of them in and of themselves makes money. But taken together with a solid product offering that is clean, well designed, and well tested, the potential to earn money goes up considerably, much more than if those steps are not performed. This is the cost of quality.

If we ask ten different people in an organization what "Quality" is, we'll get some good ball park answers, but we probably won't get a solid consensus on what that term means. It's subjective, and it's situational. Quality craftsmanship in things like furniture or in jewelry might be easier to spot, because these are areas where an aesthetic comes into play. We consider these items to be high quality because we appreciate how they look or how sturdy they are. Some of this filters into software as well, but the metaphor fails a bit because software is not a manufactured good in the literal sense like a chair or a automobile door panel. It's much more malleable, and the environment in which it works is capable of changes that a chair or a door panel is not subject to.

My favorite description of quality is one that Selena references as well...    “Quality is some value to some person.” - Gerald M. Weinberg

So ultimately, for a product to be seen as a quality product, it must first be seen as valuable. If there is no value to a person, then the quality of the item is next to meaningless.

A common refrain in small companies that don't have dedicated testers is that the developers work on code an do their own testing. They have unit tests, they have code coverage tools, they check on each other, so the role of testing is already covered. I currently work or a company for which this was the case. Earlier this year, they decided to hire a dedicated tester... me :). There was definitely a change in perspective and while I cannot say that I was a magic bullet that transformed their work from dreck to amazing (frankly, even without a tester, their TDD approach was pretty solid), I did bring a different perspective and approach, and that helped me point out areas the developers hadn't considered (or put more clearly their reasoning why they did things the way that they did). My point is that, even when teams are highly functioning without testers, the addition of one or two testers can help spot issues before their customers do, issues that they might never have considered to be issues.

The next logical jump is to think that testers will test quality into a product, but that's not how it works. Testers are not creators in the literal sense. We can tell what software is doing, but we are not the ones that make the software do that. The developers are the makers, and so long as the developers do not take on the challenge to approach solving the problems or issues in the code, the testers efforts will be a cycle of bug reporting and fixes. For Quality to truly rise, development has to also approach the processes they use and consider where issues appear and why.

Agile development has become a common catch-phrase in various organizations, but Agile in and of itself is not a silver bullet. It is an approach, with a variety of techniques, that help teams communicate better, streamline process guideline, allow for enough documentation (but just enough) to help teams be effective, with an emphasis on Test Driven Development, pairing, short iterations, and slicing the development areas into thin segments to be focused on. it's fast, to be sure, and if practiced by all team members effectively, it can be a very good development model, but it no more guarantees higher quality than any other software development method.

So how does this all come together? Testers alone don't ensure quality. development practices alone don't ensure quality. Tools and test driven development don't ensure quality. A process manual or index cards don't ensure quality. An engaged and passionate customer support team reporting issues and concerns don't ensure quality. Non o these things by themselves do, but when all taken together and all areas worked on as a fully "holistic" and "systemic" approach, *then* quality really does have a chance to develop and grow. For quality to become more than a buzzword, though, it has to be embraced and practiced by *everyone* in the organization. It can't just be a buzzword. It must be a real and active part of everyone's day to day practices.

Quality doesn't magically appear. It takes work and commitment, and yes, it's an expense. Still, the cost of not implementing and utilizing quality standards effectively may be far greater than actually implementing and living by them. Also, there is no one size fits all quality approach. every organization is as unique and different as the people and personalities that make up that organization. In a way, I liken quality to the quote attributed to Derek Bok... "if you think education is expensive, try ignorance". Likewise, if you think quality is expensive, consider what is happening without the quality improvements that are possible. Selena's not saying it will be easy, but with the right organizational approach, it can prove to be very much worth it, perhaps many times over.

Thursday, September 29, 2011

The Longest 30 Days

 On August 29th, 2011, I came face to face with a undeniable fact. Not only am I mortal, but I'm definitely breakable. Over the past 30 days, I learned way more about myself than I really wanted to, but I also had the chance to see what really mattered to me, too.

I was absent for a month from Scouts, and the world did not end. In fact, some of the youth leaders stepped up and took over my role in my place. Interestingly, the boys did say that they missed seeing me, and that they appreciated the fact that I kept things moving and progressing for them. While they liked the reprieve, I'm sure, I think they were glad to see me again Tuesday night.

I haven't been able to attend my church for the past month, but what was beautiful to see was the fact that my church (meaning the members and my friends) came to see me and bring church to me, in the truest sense of the word. I'd never been in that situation before, and while some joked with me that it must feel good to not have to get up early on Sunday mornings, I told them I'd be happy to get up even an hour earlier if it meant I was physically capable to go and be where I felt I needed to be. The real key, though, is that it taught me that there are those that would like to be in my situation, a temporary sidelined individual. Sadly, for them, their situations are more long term. It's time for me to pay back kindness for kindness :).

I learned to let my kids take the lead on things and exercise a little more freedom than I might normally feel comfortable with them doing. They did not spontaneously combust. In fact, they showed me how truly resilient they really are :). My kids cooked for me, helped me get around when I needed it, and generally turned the tables on their old man and told "him" when he was pushing himself too hard or otherwise might be geting himslf into situations that were premature or otherwise potentially dangerous. True confession time, I got on my bike to give my ankle some much needed range of motion therapy. My older daughter read me the riot act ("Dad, what do you think you're doing? What if you fell? Do you want to risk a relapse?!" Ahhh, gotta love it (LOL!) ).

I had to work remotely, with little in the way of supervision or checking in. My status updates each morning, the issue tracker and github were effectively my progress trackers, and I saw that I could be a long term telecommuter if I had to. Having said that, I really do prefer the dynamics of a team working together. Even though I so often declare myself the Lone Tester, I'm almost never an "all by my lonesome" contributor. I participate with a dynamic team and the give and take informs much of what I do. I didn't realize how dramaticaly until I literally couldn't be there to interact with the development or support teams.

Today was my first day physically back at work. Driving with my left foot (not so hard if you have an automatic transmission; thank goodness I don't still own a stick shift!), a train ride, and a four block walk (which I will admit was exhausting today ;) ), and a joyful welcome back from my co-workers, mixed with a few "dude, are you sure you should be back here so soon?!" Yes, I need to be here, not just for my physical therapy, but for my mental well being as well. For four weeks I was bed-bound and/or house-bound. It was time to get back out in the real world again, even if it meant I moved really slowly. For those who have been following this journey of mine, it would be tempting to say that it's all over, but it's not. I'm still in the boot for at least another month, and my physical therapy will continue for several more months, as it won't be until then that I know the true dimension of whether or not I'll get full use and range of motion of my lower leg and foot again. It's a bit of a windy road, but so far, I'm doing pretty well. To those who have been offering me encouragement, prayers and general good vibes these past 30 days, I am wholly grateful, more than you will ever know :).

BOOK CLUB: How to Reduce the Cost of Software Testing (2/21)

For almost a year now, those who follow this blog have heard me talk about *THE BOOK*. When it will be ready, when it will be available, and who worked on it? This book is special, in that it is an anthology. Each essay could be read by itself, or it could be read in the context of the rest of the book. As a contributor, I think it's a great title and a timely one. The point is, I'm already excited about the book, and I'm excited about the premise and the way it all came together. But outside of all that... what does the book say?

Over the next few weeks, I hope I'll be able to answer that, and to do so I'm going back to the BOOK CLUB format I used last year for "How We Test Software at Microsoft". Note, I'm not going to do a full synopsis of each chapter in depth (hey, that's what the book is for ;) ), but I will give my thoughts as relates to each chapter and area. Each individual chapter will be given its own space and entry. Today's entry deals with Chapter 1.

Chapter 1: Is This the Right Question? by Matt Heusser

There's no question that the simplest and easiest way to limit the costs of testing is simply to not do it. Problem solved. Only it's not solved, because believe it or not, problems will still exist. So Matt asks us up front, when we talk about reducing costs, are we really talking about cost reduction... or are we really asking "How can we increase the VALUE of software testing?"

There are lots of ways to cut costs, not just in software testing, but in every part of the organization. Benefts are expensive, so are salaries. Cut those and you save *lots* of money... of course, you are also likely to lose your best people, too. So that's a false economy. We could break down work into very simple, repeatable steps. This has the benefit of wringing the best "value" out of the costs needed. Once again, though, it's a false economy, for two reasons, and one that I think Matt touches on, but I'll add my own take on this. First, there is no way in software to make a true "factory or millwork" comparison. Software is not a widget. What I mean is that we do not create a single component like you would at a factory to make a cylinder casing for an engine. So breaking everything down into simple components won't work in this fashion, because there are so many permutations and variables that it's impossible to cover them all. Second, to borrow from Seth Godin's "Linchpin", if you could structure all of the work in this manner, then anyone could do it, and anyone could be plugged in and pulled out. It's a race to the bottom. To put it more succinctly, it could be a factory job... but do you really want that?

So the short answer is, we are not asking the right question if we are just asking "how do we reduce the costs of software testing?" It's an important question. It's just not the only question. Value has to be considered. The biggest problem with "Value" is that it's really fuzzy. It's very subjective, and there's no magic number that says "OK, now that's VALUE!" Think of the things that generate "value" in an organization. The clasic example is training. Is it valuable? How can you tell? How much is enough? At what point is there a law of diminishing returns? Is there such a  thing as too much training? We would instinctively say "well, of course there isn't", but how can you truly quantify that?

In the software testing world, we look at "test cases" as a solidly quantifiable metric. The more test cases you have, the better your testing will be, right? Not so fast. I could tell you that my automated test routine has 1,000 test cases. Wow, 1,000 cases. That's a lot. But do those 1,000 test cases actually really mean I am doing better testing just by having them? Of course not, you don't have any context into why or what I'm testing. That's why my saing that, out of 1,000 test cases, 995 of them passed sounds great, until I tell you that one of them is relate to the fact that the app can't send emails. That can be a ctastrophic failure if you're testing a CRM system, but you won't know that by my just quoting you a number.

So how can we use these value ideas to help steer the conversation when those in the driver's seat are all about controlling costs?

The key is that we need to be able to do a number of things at important times. Writing and using tests as examples of the requirements to help make sure the requirements are clear is the first step. Finding the most important issues early and quickly is also important. Giving good and timely information to the development and management teams so that important decisions can be made.

A few days ago, a developer that I worked with at a previous company wrote to me and mentioned something I told him while I was testing with him a few years back. He asked me why I was able to get so many bug reports early in the process. I told him that one of my "principal weapons" in the battle of software testing came from James Whittaker (who may have taken it from somewhere else, I don't know really) but that I found to be one of the most valuable first salvos on an application... look for every error message in the code, and do what you can to make those error messages appear at least once. For those familiar with the book "How to Break Software", you will recognize this as "Attack #1". The message that I got back from this developer was that that tip alone, while he was working on his most recent project, helped eliminate about 50% of the bugs that the project would have had by that point. I thought it was cool of him to write me and tell me about that. Point being, that's a simple approach of a "big bang for your buck" early testing strategy and technique that you can use starting right now :).

The ability to provide good information so that the development or executive team can make a well informed decision is really the #1 thing that testers provide, at least in my opinion. If we have any chance of really making an impact, and a dramatic one, that's where testers can make the greatest substantive changes and add tremendous value. From test reports, to meeting status, and to ship/no-ship decisions, the tester has a unique role and responsibility. To borrow from Jon Bach, testers have more kinship with journalists than with any other profession. Therefore, the "story" or narrative of the project and its fitness is one of the key deliverables of the test team. How well does your team tell its story? The story? Do you approach your testing with the intensity of a beat reporter? If not, you may want to consider it.

Finally, to up the value and reduce the costs, one of the best ways to help that process is to eliminate waste wherever possible. There are areas that are beyond our control (status meetings, email, etc. may be a mandatory part of the jobs we do) but there are ways to get more bang for the buck in what we do. One great way is to approach testing from a Session Based model. Instead of saying "I tested this functionality" show that you have completed "x" number of testing sessions (of focused time) associated with a key piece of functionality... and tell your story.

Next installment will cover chapter 2.

Wednesday, September 28, 2011

BOOK CLUB: How to Reduce the Cost of Software Testing (1/21)

For almost a year now, those who follow this blog have heard me talk about *THE BOOK*. When it will be ready, when it will be available, and who worked on it? This book is special, in that it is an anthology. Each essay could be read by itself, or it could be read in the context of the rest of the book. As a contributor, I think it's a great title and a timely one. The point is, I'm already excited about the book, and I'm excited about the premise and the way it all came together. But outside of all that... what does the book say?

Over the next few weeks, I hope I'll be able to answer that, and to do so I'm going back to the BOOK CLUB format I used last year for "How We Test Software at Microsoft". Note, I'm not going to do a full synopsis of each chapter in depth (hey, that's what the book is for ;) ), but I will give my thoughts as relates to each chapter and area. Each individual chapter will be given its own space and entry. Today's entry deals with the Forward and Preface.

Forward by Cem Kaner

Cem makes the point that we have been going through challenging economic times, and the software testing world has certainly been affected. There is no question that in challenging financial realities, the desire to control costs comes to the forefront in many organizations. But what are the costs of software testing? Can you name them directly? Are your impressions of costs correct? How about your organizations impressions? Do we want to have those who have no real understanding of the true costs of software testing (and of quality in general), making decisions just on the dollar values?

When we approach software testing and quality, there needs to be a balance. Cost is only one variable in the equation. Another vital variable is waste. How much of what we do in our day to day testing is busy-work, there because some department in an organization says they need it, but never look at the data provided? Is that waste? It is if the work that could be done is of greater value, but can't be done because we are too busy dotting i's and crossing t's. Note, I am not saying that having documentation or providing information is not important; information is the key deliverable of any tester. However, I feel it has to be the right kind of information, at the right time, in the right amount to tell a compelling story. If what we provide isn't optimized to do exactly that, then any of the "extra junk" is just that. It's junk.

So what's the answer? We as testers need to consider a different way of thinking. We need to up our game in the skills department. We need to focus on the activities that deliver high quality information and can provide as complete a story as possible so that stakeholders can make an informed decision. Learning about techniques will help, but so will learning what areas we should diminish or avoid altogether. How to do that? That's what the chapters in this book should help us all do :).


It's become a thing of legend now. Govind Kulkarni asks a fateful question on a LinkedIn group, and the whirlwind picked up momentum. 500 responses later, an idea is born. Let's create a book about reducing the cost of software testing, from the perspective of the testers themselves. Let's edit it collaboratively. Let's recruit authors from many different industries and from different countries. Let's use a wiki to share our ideas and develop the different areas of the book in parallel.

The net result is this book. Many people took  time to help coach the authors and help them deliver drafts of their topics and help them polish them until they were solid and ready to be included in the book.

There are three main areas; first, identifying the costs of software testing, and after reading the first section, you may have a different consideration of what those costs actually are and how they are approached (well, I certainly did).

The second part of the book relates to "What Should I Do?" A lot of that "what" depends on "who" you are. This book is not specifically written for testers alone. There is a great deal of valuable information for developers, development managers, executives, financial comptrollers, and others who have direct impact on where the dollars and cents of an organizations finances are applied.

The third section is "How do we do it?". There are many ideas presented from different vantage points and from different levels of experience. You may not find everything is applicable, but you will very likely find something you can take away and do right then and there.

The final section is an Appendix, and for those that just can't wait, there are key areas with immediate methods you can use to get to work cutting costs right this second. However, do you really want to prescribe medicine before you know what the sickness is? That's why I'll be reviewing those sections last ;).

I hope you'll join me next time so that we can dive into "Chapter 1: Is this the Right Question?"

Looking to Trade: Review for Review

So some of you may be thinking "Hmmm, *THE BOOK* has been released. What are the odds that Michael will be doing reviews based on that book, or a review of the book?" Well, I'd be fibbing if I said that I hadn't considered it, but I feel really weird about reviewing something that I've written myself as being self serving. You'll get two likely answers. I'll either puff up what I said and say it was great, or I'll excoriate myself and say it was terrible. It' the same with the music I wrote back in the 80s and 90s. Some of it I love. Some of it I can't stand to listen to. Funny thing is, stuff I can't stand to listen to other people thought was great. songs I personally thought were fantastic others though "Hmmm, ummm, well, it's interesting, I guess". See, I'm a lousy choice for doing personal reviews.

Still, I think *THE BOOK* really is a very important title, and I want to review it, so here's what I'd like to ask of my fellow bloggers... I want to resurrect the BOOK CLUB review, and do something similar to what I did with "How We Test Software at Microsoft". The idea is that it will be an exploration and commentary review on the ideas of each chapter, and it may take me a while to get through. I will, however, leave one chapter out, and that is "Trading Money for Time". In other words, my chapter.


Because I'd like to encourage someone out there to review that chapter themselves. I can host it on my blog here and give the reviewer guest blogger status and credit and link-backs, etc.), or you can write the review of the chapter on your own site. Either way, I want to help encourage the reviewing of this book and getting it into the psyches of testers, test managers, executives and anyone else that has an interest in or a professional stake in software quality in general, an software testing specifically (note, the two are not the same thing ;) ). If it turns out to be another contributing author to *THE BOOK*, that would also be kinda' cool :).

So, any takers? The requirement of course is that you have a copy. If you have it already, cool. If you don't, let me know an I can help set you up with a discount coupon from the publisher.

Saturday, September 24, 2011

Enjoy the Humor in the Catastrophe

Yet another of Aaron Scott's Two Leaf Clover cartoons, and the thoughts that spring to mind :). There's a certain "Far Side" glee to this particular panel, and I think it's quite funny, and at the same time, quite true to human nature. When we discover a particular fantastic foul-up, one that lasts in the psyche for "years", we tend to remember them years later with smiles.

An old phrase I remembered hearing as a teenager, and I've come back to it time and time again, is "Crisis + Time == Humor!" The context at the time was dating, something I was just becoming cognizant about. It may surprise many people to think that once upon a time I was an awkward and rather shy teenager. That doesn't really jibe with how people know me today (I have to remind them I spent ten years in the crucible of the San Francisco Bay Area music scene to help get from there to the person most people know me as today :) ).

Anyway, I had some spectacularly bad dates early in my experience, and each time I thought it was the end of the world. Given time, though, and a chance to look back, I realized that I was able to still be on friendly terms with most of the people I dated, and when thinking about the dates years later, I'd laugh about [fill in the blank] that made the date particularly memorable, usually in a cringe inducing way.

Testing often gives us these moments, where we often discover that for various reasons, we have set ourselves up for spectacularly bad results. We may not know when we start out that we are leading ourselves into a snake pit, or that we are about to open up a hornets' nest on ourselves, or that our best laid plans and ideas, heroic as they may be, have the potential to blow up in our faces. We live in a society that implicitly does not encourage mistakes. We learn from early in school that the only way to get an A is to not make any mistakes. Thus, mistakes are bad. Don't make mistakes! That's the message we get, and we dutifully do all we can to not make mistakes, and when we do, we are mortified and embarrassed and wish we could crawl under a rock and die. But what happens when we make mistakes, when we fail, when things blow up in our faces? Well, we learn! In fact, we learn better than we would had we made no mistakes at all. Oftentimes, making no mistakes has more to do with luck than with skill.  When we don't get a chance to come face to face with our mistakes, we don't get a chance to reflect on them and learn from them.

Yes, sometimes terrible, embarrassing, and painful situations can be powerfully educational. I'd dare say my best learning has come at the hands of getting the proverbial "body slam" from life. Those do a few things. They teach us  humility. They teach us perspective. They teach us about boundaries and about humanity. They're actually quite beautiful moments if we are willing to let ourselves actually embrace, an yes, enjoy the humor in the situations.

Friday, September 23, 2011

The Book is HERE!!!

It's been well over a year of work, reviewing, consideration, submissions, rewrites and just plan waiting, but today, I officially received my writers copy of "How to Reduce the Cost of Software Testing".

I've written about the process of how I got involved with the book, and the fact that I had a chance to get in because another author dropped out (never thought I'd be thankful that someone else couldn't commit to a project, but in this case, I am glad :) ), and through an initial draft, a few rewrites and reviews, my chapter was deemed good enough to be included with the rest.

Looking at the list of authors, I will admit I've swallowed hard a couple of times. Reading the back cover to see prise for "corporate test leaders, best of paper authors and keynote speakers" I keep thinking to myself "Wow, they got all those people... and me (LOL!)". All kidding aside, though, there is just something about picking up a book and turning it over, seeing that it has a SKU on it, and that you know that it is a title anyone can buy through or other outlets. Feeling the pages and seeing my name in the table of contents, reading the bio and the acknowledgments, and then going back to see the chapter that I originally wrote.

The closes thing I can compare this to is when I had a chance to have one of my band's tracks appear on a compilation album a  couple of years back, followed by a full length release of our own material. There is a giddy sense of euphoria, and then it's followed by that sense of self criticism that says "wow, but that was written a year ago. I have learned so much more since then." This is a natural thing, and I think it's good. Books, like musical albums, freeze the viewpoint of an individual in a set parameter. A blog is not the same. If I wanted to, I could edit a blog and fix things. I can't fix a released album, and I can't fix a released book. So they become artifacts of my thinking and of my experiences, sealed in a form of "intellectual amber" :). the wild thing is that, years from now, I may meet someone and they may actually say "Hey, I read your thing on 'Trading Money For Time'". they may like it, they may disagree with it, but the neat thing is, I'll be able to discuss it with them from the vantage point of knowing they actually read it :).

So yeah, today is a day of celebration, and it's a bright point in what has been a really challenging month. Today's mail brought a huge smile to my face. You know what else would bring a huge smile? Knowing my friends in the software testing world went out to get the book, read the chapters and enact the ideas in their organizations. Were that to happen, then we would know that the book was worth it to everyone out there. It's a labor of love we all participated in, and now it's out in the wild, we hope you'll hunt it down and use it in your day to day interactions. either way, it's an exciting time, I'm curious to see what will happen from here on out.

Thursday, September 22, 2011

Do What You Can, Where You Can, When You Can

For those of you who are wondering what's up with this, it's a cartoon my friend Aaron Scott draws called "Two Leaf Clover" and today, in my current state of affairs (broken leg, limited movement, etc.) this was both funny and painful at the same time. I've come to really appreciate this in light of my recent events.

So often, there are a million things that vie for our attention and our limited resources. OK, a million things may be an exaggeration, but thousands of things is not, especially in this always on, always tuned in world. Where we spend out time and our energies says a lot about who we are as people. It certainly says a lot about me.

The danger we face with so many things that need to get done is we often end up doing very little, or in some cases, we end up doing nothing (analysis paralysis). In those instances, it can be amazing to see what happens when you stop and reconsider what you really should be doing.

For me, I had a chance to really reconsider all of this in the hospital. There I was, attached to a morphine drip, getting oxygen through a tube, and the most demanding task I could muster was making sure I was getting in my ten breaths on the breathing measurement apparatus each hour (something they do after general anesthetic to make sure the patient doesn't develop pneumonia after their surgery). If I ever wanted to discover what it felt like to genuinely be in a situation where I could get nothing done, that was it. It was the worst feeling ever. I felt totally useless.

Over the past few weeks, I've come to grips with the fact that I've had to learn to deal with progressively getting stronger and having the ability to move more and for longer periods. In all of that, there was a certain "clarity" I realized. Because I couldn't be in a million places, many of the things I always believed I had to be 100% on about, I was able to let go of. I gave my assistant scout leaders the ability to plan the meetings and direct the boys in my scout troop, because I couldn't do it even if I wanted to... and they've done a great job. The AST BBST class is underway right now, with two terrific assistant instructors helping me, and filling the blanks that I'm having trouble filling in at the moment. In some ways I feel bad about this, but in others, I feel great, because I'm giving them the chance to do what they need to do, their way, without my sticking my nose in everywhere... and they are oing a great job.

One of the discoveries with limited movement and having to drop so many things is that I've discovered there are other areas where I am able to finally put some attention to. I've been able to read a number of books and get into greater detail on them. Many of them are in beta format at the moment, so I won't be able to review them for awhile, but once they are released, I may have a glut of reviews to post :) ). I've had a chance to dig into my company's ways of using Cucumber and see unique ways of approaching tests and getting them to pass on different environments, which has helped me raise new questions about how we test, where we test and why.

It's interesting how many things we can accomplish when we put away the old adage "there just aren't enough hours in a day". That's a lie. There are enough hours. We all get the same 24, yet some people are masters at their craft while others seem to accomplish nothing day after day. Most of us fall somewhere in between. It's not that we don't have enough hours, it's that we make choices in those hours that go contrary to what our believed goals are (yes, I said "believed goals", as if we were to match our supposed goals with our actual output and what we actually spend out time doing, I'll bet many of us will see a disconnect). For me, I've had my world greatly shrunk, but that has actually been a blessing, too, as it's shown me the true length of a day, and how much can be accomplished when we plug in and get to it.

I'm by no means perfect, and yes, even in my current shrunken world, there are still plenty of diversions and time wasters, but they are also greatly constrained. I've no place to go, so commute is out of the equation. I cannot visit in person, so activities that require my physical presence cannot be accommodated now. This opens up literally hours of every day for those pursuits I said I never had time for before. I've come face to face with a golden opportunity; my world is focused in one place. My goals likewise are focused in one place. I may never get an opportunity like this ever again (and frankly, I don't want an opportunity like this ever again, broken bones are no fun!).

The simple fact is, for every good goal that needs to be completed, some other worthy thing will have to be sacrificed or delayed to make that good goal come to fruition. We can't have it all. Right now, I can't even have 10% of it all. But  we can do a little each day, or a lot each day, depending on what we are willing to give up to make the good goals come to be. Ultimately, it's all about doing what we can, where we can, an when we can, in the 24 hours each day we are allotted.

Tuesday, September 20, 2011

Book Review: The Manga Guide to the Universe

Begin Disclaimer. 

First, I want to make clear that my reviews often get spread out in a bunch of different areas and are posted to various sites. I was given a copy of this book to review by No Starch Press, but I am an independent reviewer and have no connection or financial incentives in the books or in their publisher in the US or elsewhere. I feel it important to mention this when I do book reviews and post them, so that people realize my review may appear in multiple places, but it will appear in TESTHEAD first unless otherwise agreed to (i.e. my O’Reilly Reviews appear there first and then on my site later). 

End Disclaimer.

First and foremost, this is a fun title. It’s fun because of course it’s a manga, and usually manga titles are dramatic, silly, funny, poignant and ridiculous… often all at the same time. It’s part o the charm of the medium. No starch Press has released their latest installment of “The Manga Guide to…” series, and this time they are taking on a whopper of a topic… The Universe!

For me personally, there is a level of fascination to this topic that goes beyond my interest in the stars and what might be “out there”. This is also a great book to open one’s eyes to epistemology, or the study of what we know and why we think we know it. At the beginning of the series “The Day the Universe Changed” (BBC series from the 80’s), James Burke starts out and says that a student or colleague of the philosopher Wittgenstein was talking to him, and commented on the fact that previous generations were so foolish to believe that the Earth was the center of the universe, when clearly the Earth and the Moon revolve around the Sun. Wittgenstein’s answer was quite clever. He said “Yes, I suppose so. But I wonder what it would look like if the Sun really did revolve around the Earth.” His point being, from our vantage point… it would look exactly the same!

It’s with these ideas in mind that "The Manga Guide to the Universe" begins its exploration of the Universe. It starts with our three protagonists trying to come up with a topic and a script for their drama club. If they don’t, they will have to close own the club (cue stock music for tense drama ;) ). One of the stories they consider is the Legend of the Bamboo Cutter, and ancient folk tale within Japan and a telling story of a belief in extra-terrestrial life. It’s from this area that we are introduced to the main character’s brother and his Professor who teaches about astronomy and astrophysics. The first part of the book discusses the discoveries and setbacks that scientists had faced over millennia to explain their world and its lace in the cosmos. We go from Ancient Egypt and Ancient Japan, through to the discoveries of the Greeks and the scientists in the Middle ages, the renaissance and beyond, to show how we grew to understand, postulate, test and finally prove that our place in the universe was not the center, with everything revolving around us, but that we were, to quote an old show from my youth, “a big blue marble in space”, rotating around a sun the way the other planets in our solar system do. Like other books in The Manga Guide to…” series, each chapter is broken up into story panels like a traditional manga, but then a few pages of description, mathematics or physics will go into greater depth about the topics just covered. You will learn a lot from just the manga panels, but you’ll learn much more from reading the explanation pages, too.

The story develops with the student trying to find a way for the star of their play (a girl found inside of a stalk of bamboo by the bamboo cutter) that declares she’s from another world and must return there. the search for a possible home for the girl is the development that leads the exploration through an out of our solar system, into the Milky Way galaxy, beyond our galaxy to local groups and the ultimate size and shape (we think) of our universe, and the various theories that help us measure these ideas.

What I found to be most valuable, again, goes back to epistemology, and showing what we have learned over the years, and how testing that knowledge has either reinforced ideas, or led us to new ideas. The mathematics used in this book are, well, daunting and massive. The sheer size of the universe as we perceive it is breathtaking, and it’s exactly this order of magnitude thinking that makes this book refreshing and fun. Rather than drown the user in gigantic numbers, we see variations such as astronomical units (1 AU is the radius of the distance of the Earth to the Sun). From there, calculations using triangulation and other geometric means help explain how we can determine the massive distances, and also explain some thoughts about the potential of multiverses or a “curved universe’ where the edge of the universe is reached when we come back to our starting point. Confused? After reading this book, you won’t be (well, again, it’s theory and pretty wild stuff, but you can definitely appreciate the logic behind it.

Do no think to yourself “children’s book” when you see this title. This covers some intense stuff that adults might find hard to follow. Astronomy, Astrophysics, Cosmology and even Science Fiction (appreciating the structure of and the keeping a world view coherent) are covered in this title. For fans of these sciences, this is a slam dunk. The Manga Guide to the Universe is a fun and engaging title. To my fellow testers, all of the above are true, but read it for a greater appreciation of how we acquire knowledge, and how each discovery is connected to those that came before. Testers will also appreciate the fact that our forefathers, having ancient an rudimentary tools, worked out remarkable solutions for their day, and some ancient discoveries still stand the test of time; if not 100% accurate, they are really close. So if I have piqued your interest, check out this fun and engaging book. Even if manga isn’t your thing, there’s plenty here to keep even hardened science geeks and armchair astronomers engaged.

Sunday, September 18, 2011

Just Because I Can't be at PNSQC, Doesn't Mean You Shouldn't be There

As part of my recuperation, I had to make some tough decisions. Without a clear idea of how far along I'd be, or how I'd be able to move (and so far, that movement is still very little), I had to come to grips with something this past week... I asked to have my name withdrawn as an presenter at the Pacific Northwest Software Quality Conference for 2011.

I am quite bummed about this, as this was going to be my first "full talk" at a conference. I did a 20 minute Emerging Topics talk at CAST in Washington last month, but this would have been my first full talk presented at a conference and published with the proceedings. On the bright side, I did receive a piece of good news; even though I have to drop out of presenting the paper due to physical limitations, they are going to publish it with the 2011 proceedings, which makes me rather happy.

My paper is titled "Delivering Quality One Weekend at a Time"... would anyone care to venture a guess as to what the topic is ;)? Yeah, OK, no more teasing... yes, this is a paper specific to the lessons that I have learned from facilitating Weekend Testing here in the Americas, as well as participating in the Europe and Australia/New Zealand chapters.

But just because I am not going to be at PNSQC, if you are on the fence and considering whether you should go or not, I say GO!!! The program committee has put together a great group of speakers, ranging from Goranka Bjedov from Facebook, BJ Rollinson from Microsoft, Marlena Compton from Mozilla, and OK, I guess I can mention that one dude, Michael Bolton, who is one of the invited speakers :). Seriously, it's a great program with a lot of cool topics and interesting tracks. It's taking place October 10-12, 2011 at the Portland World Trade Center (very close to Pioneer Square and easy to get to via light rail) and it promises to be a lot of fun.

Believe me, if I could be there, I would be, so if you are still thinking about going, but haven't pulled the trigger, please go over to and Register. It will be worth your time. Oh, and you better believe I'm going to come out swinging for 2012 :)!!!

Wednesday, September 14, 2011

Twisto Changeo: TWiST is Changing :)!!!

As man of you know, one of my side things that I do is I produce the TWiST Podcast along with Matt Heusser. Tomorrow or Friday we will post the last of the "old format" shows. Wait, did he just say the "LAST"?!!

I did, but don't worry too much, TWiST is still active, in the works and Matt is still behind the microphone and I'm still behind the production board. We did, however, decide it was time for a change in the format and the approach we took. Rather than just having Matt talk with a single tester in an interview format, we decided to experiment with a panel format and a designated topic to guide the podcast.

So what does this mean? It means that there will be multiple guests on a typical show, usually four or five. It also means that I'm making a bit of a move out of the production booth and onto the microphone more. So far, we've recorded six shows in the new format, and I'm part of four of them, so I'm looking forward to this new approach. we hope you will, too.

Remember, TWiST is still going to be coming out on its usual schedule, which is weekly, either Thursday afternoon or Friday mornings. Our goal is to make the best software testing podcast out there. We hope you'll enjoy listening to the new format, and if you'd like to be a guest on the show, let me know and we can see about arranging a forum and topic to include you :).

Sunday, September 11, 2011

Two Memorials, Two Issues, One Feeling

I hope you will all forgive me today, but this is not a testing blog entry. Instead, it's my dealing with feelings of this past weekend and two days that will forever be branded into my memory.

September 11th, 2001 has become synonymous with terror and destruction in the American psyche. We saw on that day the worst of what the human mind can accomplish. We also saw something else, too; the heroism and bravery of firefighters, police, emergency response teams and others and the sacrifices they made to save who they could, knowing they might doom themselves to share the same fate as so many others. The decade that has followed has had its own challenges and issues, some of which have borne good fruit and some other we may well wonder if it was all worth it in the final analysis (which is far from conclusive at this point, and besides, this isn't a political blog, it's a testing blog).

There's another anniversary that is remembered two days earlier than this as well, and it also reminds me of the tragedies of life, but also the immense heroism of our own firefighters, police, emergency response teams and others. On September 9th, 2010 a gas main ruptured in my little town of San Bruno, CA, claiming many lives and scores of homes in a neighborhood adjacent to my own. While the 09/11 attack was devastating and heartbreaking, these were people who were 3000 miles away, and that I had little direct and personal connection with. The events of 09/09 were practically in my backyard, and had a devastating effect on people and families that I personally know and care for and about.

As I look back on these two days now, I could choose to focus my anger and, yes, maybe even hatred towards those who were responsible for these occurrences (09/11 being a direct attack, 09/09 being a tragic but perhaps all too avoidable accident), but in truth, anger and hatred don't change anything. They don't make anything better. They don't make us better. So today, as we consider the tenth anniversary of 09/11 and I also consider the first anniversary of 09/09, my question is the same for both... what can we learn from this? How can we make ourselves better people in light of this? Again, I have no interest in trumpeting a political solution or shilling for a political answer. I much believe that the real power to combat these things is in our local hands and in our direct interactions with people. I do not pretend that there are not great forces that are looking to take advantage of these situations, but those are outside of my circle of influence, and there is precious little I can do there anyway. No, the only place I have any effect is in my own direct interactions with people.

It's my desire today that we focus on each other as people, as friends, and mourners, and as those who have loved and lost and are rebuilding our lives, in the ways we know best. Help those around you rebuild, give them a shoulder to cry on, let them know you are there for them, and most importantly, do not forget these things. A populace that forgets its history is doomed to repeat it.

Friday, September 9, 2011

We Can Never Be 100% Safe

It's now been 10 days since my accident, and I've had a number of people contact me, offer their condolences, and on more than a few occasions, offer me suggestions as to how I could have been more safe under the circumstances. They range from abstaining from skateboarding to having various protective gear options in place. Truth be told, for many of the way that skateboards are made to be ridden, there are indeed very practical items of protection, many of them I wear in different circumstances.

A helmet is a given much of the time. Knee pads are a great choice if you are going to be skating a vert ramp or park features. Elbow pads may also be helpful. When I was a kid, thick padded leather gloves were all the rage, with big round leather disks in the palms. I haven't seen those in years, but I found them exceptionally useful when I used to street skate as a kid. There is even a pair of padded undershorts that you can buy (Pro-Tec makes them) that cover your hip bones and tail bone.

All of these pieces are great, but there's one piece missing from this "body armor"... there's nothing to protect the lower legs from the impact fracture I developed. Well, I shouldn't say there's nothing. I suppose I could skate with motorcycle racing boots. Now they would definitely have the stabilizing necessary to protect my bones. Only problem is, they are so bulky and inflexible I wouldn't be able to skate or maneuver with them. Most skateboarders have figured this out, and have accepted the fact that their Achilles Heel is, well, right around their Achilles Heel. In short, skateboarders have come to realize that, try as hard as they might, there really is no way to make their sport 100% safe.

As testers, we likewise have to realize there is no way that we, or the developers, can make our products 100% bug free or risk free. Like the skateboarder, we can mitigate risk as much as possible, but there are going to be areas where, just for the sake of movement and flexibility, we will accept a level of ambiguity and risk, knowing that the worst scenario could happen but is unlikely for most. It also means that when those perfect conditions line up, the odds are that anyone, no matter how well protected (or tested) will have a failure. It just happens sometimes. For me as a tester, that means that I need to be alert and aware of the fact that there are lots of possibilities that I may not be aware of, and that awareness is the quickest way to mitigate that risk and act upon it. In skateboarding, I can gear up and be cautious in the way that I ride. Either way, the responsibility is mine, and I have to be aware that, no matter what I do, there's always a chance that pain could be around the corner.

Of course, I could walk... but that doesn't erase all the risks, either, just those associated with skateboarding. We can have a chat about the safety risks of walking another time ;).

Wednesday, September 7, 2011

Would It Hurt to Check Your Facts?

So for those of you who are blissfully ignorant of Facebook, you may stop reading now. Well, OK, no you don't have to stop reading, but there is a trend that is going on over there that is starting make me a bit annoyed.

It's a frequent thing for people to post messages that are urban legends, hoaxes and other oddities, but the most recent meme is a "fix" for Facebook settings that doesn't even do what it is purported to do. In short here's the current meme:

Facebook has changed its News Feed AGAIN, so that by default, you can only see updates from people with whom you've recently interacted. To change this, click on 'Account', then 'Edit friends' then at the top left, click "All Friends." Most Importantly... Re-Post this. Otherwise, only a few of your friends will actually see your posts.

Seems innocuous enough, even nice, all things considered, except for one small detail... the advice listed above doesn't work. In fact, it's a totally different piece of functionality. It's a great approach to filtering or not filtering your friends list while you are editing your friends list, but it has "zero" effect on your news feed or wall posts. How to tell this? Because you can see in the replies how many people are saying "hey, I can't save this" or "why does it always go back to "most recent""?

Seemed like a testing challenge, so i decided to dig for a couple of minutes. First, I remember dealing with this awhile ago, and it wasn't in the spot that everyone mentioned. In fact, it was in the space called "Edit Options" (which is accessible both at the bottom of your news feed page, or from the News feed options drop down in the upper left hand corner of your Facebook wall. From there, the light-box that appears only has two choices, your most frequently interacted with friends, or with all friends and pages. What's more telling that this is the right place to go, is that there is an actual "Save" button, and the save button stores your choice. Zounds!

OK, some of you are probably thinking "why are you telling us this, why not tell the people on your friends list on Facebook?!" The thing is, I've already done that. In fact, the point of this blog post is only peripherally related to that. The real point of the post is "how often do we regurgitate advice just because someone else said it?" This rose to the level of a meme; so many people posted the misinformation that it was getting to be comical. what's even more telling is how many people who said "hey, thanks for the tip, did what you suggested and its all better now!" Ummm, no, it's not all better. You didn't even accomplish what you thought you accomplished. Even more, people kept posting this and reposting this, making me wonder if we just want to get "cool points" for posting and reposting something so we can be part of the "cool crowd", or if we actually take the time to look at the message and see i it stands up to the smell test. This time around, as I looked at the posted solution, I realized it couldn't be a solution. It wasn't even dealing with the same functionality.

So to my fellow testers, I am sure you all do this, but just in case, before you re-post or re-tweet something from a source you think is cool or knowledgeable, try it out for yourself first, and see if what's being posted really is doing what it says it's doing. 

Monday, September 5, 2011

Speaking of "Labor Day"...

To see original comic, go to
First, I want to wish all of my fellow testers in the United States a Happy Labor Day. For everyone else, hey, hope your Monday is going well :).

This is a first for me, in that it's a regular partnership with some one I know. Aaron Scott is a cartoonist and creates the strip "Two Leaf Clover". We were commiserating over the fact that both of us were spending "Labor Day" actually working (him on his next cartoon, me on the next TWiST podcast). As we talked, I thought it would be fun to share his cartoons with TESTHEAD readers, because he pokes fun at tech, things often being over complex, or just plain the silliness of certain geek appropriate things. In short, I like his sense of humor, and I find that sometimes his cartoons inspire blog posts. so I've decided when he has a cartoon that I want to respond to or delve into as a blog post, I'll feature the comic, talk about it, and have a link back to the original.

As for today, it's Labor Day, does this really need any more commentary ;)?

Saturday, September 3, 2011

WTA19: Bulls and Cows and Exploratory Testing

First, I want to take a little time to say thanks to Albert Gareev, who has for all practical purposes been my right hand dude when it comes to all things Weekend Testing Americas. this week was his first chance to fly solo, necessitated by the fact that I really couldn't get into a comfortable position to type for an extended period (we're working on that situation this weekend, btw). Albert ran the session himself, kept everything on track, and the session itself was fun, too.

This is not an Experience Report per se. well, it's my experience report being on the outside looking in for a WTA session. I enjoyed being "the tester" again, and being able to actively participate in the challenge. There's a site called and one of the games is called bulls and cows. It's a simple number guessing game. The system will pick a number and you will pick a number. You define the number of digits and then you pick a number. Based on the number you enter, the game will respond back with "x bulls, y cows", where bulls represents a correct number in the correct position, where cows represents a correct number but in the wrong position.

Our goal was to approach it as an exploratory testing exercise and see if, through our notes, we could explain the methods we used to solve the puzzle. Many of us used different techniques, and I'll let others blog about their approach, but I'll share mine. My goal was to see if I could determine the correct numbers and their placements as quickly and with as few guesses as possible. To that end, I worked out the following strategy:

1. enter various 4 digit values in quick succession with minimal repeat of values (2435, 6179, 5862, 8765, etc.) It may have been luck but I was able to hit a cow on the first turn, a cow on the 3rd turn and a bull on the 4th.

2. Looking back, I saw that the cows and the bulls all had the number 5, so i went and played around with numbers around 5, including "5555" which gave me 2 bulls, 0 cows (ah digits can repeat!). Further tinkering showed me that the 2nd digit and the 4th digit were 5s. from there I tried to see if I could get other numbers to indicate if I could nail down cows (number values) for the first and third digit, thus I cycled through [1515, 2525, 3535, 4545, 6565, 7575, 8585, and 9595]. All gave me the same answer, 2 bulls, 0 cows.

3. Well, that's weird, I went through all the possible digits... oh no, wait, I didn't, I forgot about "0". OK, just for grins... "0505"... and with that, I got 4 bulls!

This is a classic example of using exploratory testing, based on my own context and based on my own situation at this given time. Another set of numbers could be picked, and were I to run the exact same set of steps, I would not have gotten the same results. In our everyday testing, we also will find that making a script for our tests will help us one time, and may make for a good rule of thumb as a basic checklist, but if I played the game again, I'd need to approach the problem slightly differently.

Some of the examples were much more complex, and went into far greater detail than mine did, but the basic premise is the same. the notes we make, even when we play a simple game, can tell us a lot about how we test and how we can improve the process.

Again, my thanks to Albert for leading today's session and letting me for all practical purposes a lurker today. It's good to know that Albert can fully run these sessions and I don't have to worry. Albert and I would likewise enjoy some company in having more people ready, willing and able to facilitate sessions. If you're interested, by all means let me know.

Friday, September 2, 2011

Dealing With a Much Constrained World

I've often wondered what the life of a prisoner would be like. Having to have every aspect of your life regimented, totally focused on a tiny area, with the most minimal of movements possible, perhaps to go to the washroom being the big movement of any given day. That's exactly the world I have to live with right now. Since my leg break and the subsequent surgery, I've had to come to grips with the fact that my wide moves, broad brush strokes and unlimited amounts of energy are severely curtailed right now.

I'll confess the lack of movement didn't come as much of a surprise. I knew that I'd be severely limited after I got confirmation of a broken bone, and especially after news of the need for surgery. What I wasn't prepared for was just how much energy would be consumed by having to do the most simple things. I don't mean to be gross or nasty with any of this but this is my reality each day, and much as I hope it will fade into memory soon, right now it's very real and very apparent.

First, I have access to my bed, where honestly i have spent 23 of 24 hours the past 4 days (I've calculated that I've been in a prone position for 95% of the time since 08/29/2011 at 6:15 PM). First it was a hospital bed, hooked up to a morphine drip that I decided I couldn't stand after the first day (If I have to choose between discomfort and nausea, discomfort wins every time). Having thrown up all of my food from the morning and afternoon on Tuesday, I decided it was best to just not deal with the pain meds unless I just couldn't take it any more. There were plenty of moments, to be sure, when the button won the battle of wills, but by Thursday morning, I had mostly weaned myself off of the morphine. The fact that they were giving me Percocet pills certainly helped matters, but even then I tried my best to not have them give me too much. I spent a lot of time sleeping/dozing, because literally every movement felt like an Olympic event. Short bouts with physical therapy were utterly exhausting. We joke about on crutches when we are fine, but boy is it a different matter when you really, positively cannot put weight on a limb, and if you do, LOOK OUT, because that pain is going to be INTENSE.  Thus, the bed becomes the comforter and the prison all in one.

The next boundary, honestly, is the bathroom. That's about the farthest in the house I'm willing to travel right now, and it's an adventure in and of itself. In the hospital, you are given a jug to relieve yourself; if you can make the trip to the bathroom, by all means do so, but truthfully, the amount of energy required to do that just had me grab the jug and be done with it (add to the fact that a continuous IV adds a lot of water to your system, and yes, you go... a lot!). Here at home, I know that each trip is going to be about 8 minutes round trip, and that's if I'm quick and focused. Most of the time, it's a matter of noticing you have to go, slowly lowering your foot to the floor without jerking it, running twinges of pain throughout your body, grabbing the walker, hobbling on your good foot to get to the  washroom, settling down to take care of things, then preparing with all your strength to stand up on your good foot, walk back to your bed, and pull your leg back up onto its elevated position ("leg must be elevated 22.5 hours a day, elevated meaning the broken portion must be higher than my heart").

From there, I have my time back again. This is something that, honestly, I never gave a thought to before. Now, every possible nuance that can save me a grunt here, a step there, a huff of energy someplace else, I'm going to figure it out. My bathroom breaks have become a clinic in the art of performance testing and efficiency (LOL!).

Ergonomics takes on a whole new meaning when you have to be prone and your leg has to be elevated above your heart. You tax muscles in ways you never taxed them before. My lower back is bearing a lot of strain. My right knee is getting stress by having to elevate and compensate for a section of "dead weight" leg that, if jostled in just the "right" way, makes for a solid grimace if not an outright grunt or moan. Gang, I love to play tough any chance I can get, but really, this taxes you like nobody's business. It's just plain tiring to do even the most basic of movements. It's amazing, I gave my lower right leg not one minute of thought before Monday evening. Now I can't stop thinking about it, and that in and of itself is an immense emotional labor strain.

So are there any good points to all of this? For me the answer is yes. The Internet and communicating via it is a saving grace right now. It's funny, so much has been said about the power of the Internet and the tools and services we used, but really, it all comes down to two things; the ability to communicate with people we care about and the ability to learn something new. Both of those are helping me now like never before. The outpouring of love and support by friends, family and co-workers has been astounding and really heartfelt. What's more, I've had the chance to sit down and examine things in ways I hadn't considered, or with time I otherwise would have gone off to do something else. There's nothing incidental in such a confined world. For me, everything I do has intense purpose right now, because everything I invest my time in, no matter how small or big, has a larger than average energy cost. My body and my existence has become a "gas guzzler" of a life, and in some ways, for way too little MPG, because the biggest lesson of all is this...

I am stuck with a finite amount of energy any given day, and really, it goes very quickly right now!

I may want to do a whole bunch of things, I may want to learn more about ruby and cucumber and agile testing methodologies, but no matter how much desire I have, or how much focus or attention, there's this thing called "energy" and once it's gone, you can't just will it to stick around. It's gone. This, gang, is a very new experience for me. I've always had a deep well to pull from in the past, and maybe I still do, but this week, that well has run dry a lot. When that happens, I've been known to nod off in mid sentence, in the middle of an application, and wake up an hour later thinking "OK, where am I and what was I just doing?!" This is horribly distracting, and it's frustrating, too. I'm hoping that as time goes on, I'll be doing this less and less, but really, I could do without this little side effect any day now (LOL!).

So there it is, life inside my tiny bubble at the moment. Overall, I'm upbeat, even if it may not seem like it. There's new challenges to face every day, and new ways of looking at the world that I've taken for granted. New paradigms promote new ways of thinking about things, and thus develop new paradigms as well. Why knows, this may be just the period of time that I need to really learn ruby, or to really get into the nuts and bolts of web design with CSS3, or any number of things. I may be able to work through and finish the stack of books that has been growing and waiting for me to have "the time" to read them. Well, I have no excuse about "the time" any longer. The energy? that remains to be seen. Worry not, friends, I pride myself on being chipper, and these days are no different than others I've passed. They're a little more confined, to be sure, but that's no reason for me to get all down on life. Sometimes the best ways to make a "break-through" is to make a "break with" (please pardon the pun).  I've got a new chance to really do and learn some interesting and amazing things, and honestly no excuse not to do them (well, there's always an excuse, but I have quite a lot fewer of them at the moment ;) ). In some ways, I'm interested in learning more about myself in the coming weeks. I hope that what I learn will be positive and uplifting. I hope you'll let me know as well :).