The Calm Before the Storm: STP-CON, Spring 2013

I arrived at San Diego International airport a little later than I had hoped to. The delays were cascading throughout the day, and each delay caused another to be an issue. As I mentioned in my previous post, the delay caused me to miss the group outing at the Padres game, but that missed opportunity led to another one instead.

Matt Heusser was in the main bar area talking to a number of people that I had not seen before. It turns out that most of these were co-workers of his working with him at his current consulting gig, and so I had a chance to spend a few hours talking about testing and some other random topics (New Orleans, shipping live crayfish, and the things in our lives that brought us to some major decision points) all wile overlooking the San Diego Bay from the corner windows of Island Prime, a rather excellent steak and seafood house. Great food, and great conversation.

As we walked back and the group dispersed, Matt and I saw  Mark Tomlinson, James Pulley and Andy Tinkham siting in the back of the bar area, so we continued the conversation for a couple more hours, talking about the challenges of addressing security and performance, and having confirmed my earlier thoughts that getting someone as a tester well versed in both software security and software performance, along with automation skills, was akin to looking for a purple unicorn. I also had a lot of fun discussing my ideas for my "Let's Stop Faking It" talk that I will hope to present later this year. In addition to helping me clarify some of my ideas, they gave me a number of new areas to consider, including some rather old books that deal with software systems architecture, as well as some hacker journals I would be well advised to research.

That's the great thing about these conferences. Sure, we give a lot of of press to the talks and presentations (I hope so, it's a Lion's Share of why I am here in the first place) but more than the actual talks and presentations, it's what happens outside of the official talks that often make the biggest difference. The conference hasn't even officially started for me, and I've already had the chance to spend six hours with people dealing with big issues, big ideas, and willing to challenge my world view and way of thinking. Not a bad start at all, to say the least. Here's looking forward to what tomorrow and the next few days will bring. As always, I intend to do my best to bring you all the details as they happen, or at least as close to that as possible. Please follow along with me, and let me share what I learn with you.

For Sanity's Sake, Allow For Slack

I had booked my flight weeks ago, had the time frame dialed in just right, and at the last minute, an opportunity presented itself. A number of the participants at STPCON decided to rent a box at Petco Park (where the San Diego Padres play). My flight came in at 5:30 p.m., the game started at 7:00 p.m., with pre-festivities starting at 6:00 p.m. If everything worked out right, I should be able to make that.

I think you all know where this is going, right ;)?

Well, as I'm sitting here, waiting for the flight, I have just heard over the loudspeakers "we are sorry for the inconvenience, but the flight to San Diego has been delayed by..." well, it's not really relevant how much. The point is, the game will go on without me there. Ah, well!

Last year, I did my best to book flights to get me to New Orleans, and likewise, that flight got delayed. This delay, however, was a much more troublesome one. I actually missed my connection flight, and no other flights would be available until the following morning. Net result was that I slept on the floor of the airport in Houston to get on the first flight out the next morning.

Both situations suffer from the same issue... planning without allowing for slack. We want to believe that everything will go well, that everything will work in our favor, and that we will be able to do what we need to so that we can get to our respective places, do what we want to do, or otherwise meet some goal. The simple fact is that, in our very regulated world where things are designed to run like clockwork, when things go wrong they tend to go "very wrong".  If we plan for things to go very wrong all the time, we're not going to get anything done, but if we plan for a little slack time in the things that we do,  then we find that we can absorb many of the issues that come our way, with much less need to to have to alter plans when things don't go our way.

As for my plans for tonight, I've already sent the news along, so if you hadn't signed on for the Padres game tonight, and you are at STPCON, and now wish you could go, have a chat at the registration desk and say "Michael Larsen can't make it, can I get his ticket?"

Updated: turns out there's a wait list for tickets, so it'll be claimed for sure by someone. I'll see you all as soon as I get there ;).

Getting Beyond The Slogans

This is part of what I will likely be working into a future talk. That talk, by the way will be in a place I'm not quite at liberty to discuss just yet, but once I've been given the go ahead and confirmation to shout it from the rooftops, rest assured, I will.

So, what does this odd slogan have to do with anything? Keep reading ;).

A few months ago, I wrote a blog post for Zephyr titled "Let's Stop Faking It", and in that post, I gave some thoughts as to how we could get out of this mindset. Initially, I said there were four things we could do:

1. Declare a “Not Faking It” Policy (stand up and admit you don't know what you're doing)

2. Start Looking For Ways to Remove That Ignorance (figure out how to fill the gaps)

3. Find People to “Jam” With (look for people with skill to emulate)

4. Do Not Be Afraid to Ask “Stupid Questions” (which, really goes with #2)

As I thought about how I might expand on this idea, I came up with another thought I wanted to add... eliminate needless jingoism, or more to the point, be "less partisan, more observant".

This bumper sticker comes from a site that I adore, and they specialize in Nuanced, Ambivalent, or Guarded Stickers. This is one of them, and yes, it's the wording that I love. they have several others that are equally as good, but it's the point that the sticker makes that I want to emphasize with this post today. When we make ourselves partisan, we miss a lot of what's going on around us.

First, a bit about my personality. I am rabidly non-partisan. It's not that I'm not willing to "stand for something" (I absolutely am), I just refuse to do so blindly. I'm not much of a tub thumper when it comes to getting into people's faces for causes... well, except for snowboarding; that's something I love with irrational abandon, and I'll extol its virtues until I'm blue in the face. However, if you like to ski, I'll say "great, let's go hit the hill and make a day of it!"

When we allow ourselves to be wrapped up in sloganeering, or what I call the "Home Team" mantle, we are doing so in a way that cuts us off from really learning something. When I was learning Ruby, I did everything in my power to ignore any framework or structure that didn't use it. That meant that, if I wanted to use a language to do something, I forced myself to focus on Ruby. There's nothing wrong with that on the face of things, but in truth, if we do it all the time, we stifle our understanding. When I moved over from Sidereel to Socialtext, I left an environment that was Ruby centic and came to one that was mostly based on Perl. OK, now what is that Ruby foundation going to do for me? Surprisingly little... and surprisingly, a lot! Now, I'm looking at code modules that are written in Perl, and sometimes I think "oh, this would be so much less of an issue in Ruby", but sometimes I also notice "Hey, that's kinda cool... Ruby doesn't do that!" In short, letting go of the jingoism, it lets me see other possibilities that a "rigid mind" wouldn't allow. 

I will admit, I can be a "fan" of things as much as the next guy, and I'm not saying "don't be a fan". What I am saying is "don't let your fandom get in the way of how you see things".  Don't let your enthusiasm bias you to what could happen if you were more detached, or less "emotionally invested". If you're not willing to shut it down completely, OK, but make it a mental exercise to try. Think of ways you could approach a problem and remove your "favorite thing" as the default option. Just for a while. Try to interact a different way. After doing so, do some introspection.What did you learn in the process? I'm guessing quite a bit. It may be positive, it may be negative. Either way, it'll probably get you closer to actually understanding what you want to know than if you just grab for the default preferred option. 

Onboarding the "New Tester"

Our little team is growing! What started as a single person covering all of software testing has grown into a small team of senior software testers, with additional support from contractors and interns. Additionally, we also had another Senior QA Engineer come on board last week. I was asked to shadow him and be his pair and mentor so that we get everything up to speed.

Having gone through a lot of these situations myself, and having taken copious notes, I figured we'd be on Easy Street in no time. I'd just show him where I stubbed my toes, and show him how to avoid them.

We always say that we will make it smooth for the "new tester" because we've already walked the path, and we'll show them the way. The problem is, we know the path, and we've laid out what we believe to be good trail markers, but in many ways, the path we have laid out is really only good for us. As I complained earlier about the "implicit knowledge" the team has, unless I'm going to spell out to the very most intimate minutiae of what needs to be done, yes, there's a lot of implicit knowledge that I'm expecting people to have and understand.

Just because I know backwards and forwards the steps to a process doesn't mean that the obvious things to me are going to be obvious to them. Sure enough, after a few fits and starts, we ironed out the issues, and we got everything set up and finally running. The process taught me that things that I know are important, and are plain and obvious guide markers to me, may be totally missed by someone else, not because they aren't smart or accomplished at what they do, but because their expectations and experiences might be slightly different than mine.

When we get the chance to bring someone new on board, let's try to resist the temptation to give the bare basics and then let them fend for themselves. Instead, let's walk them through areas we discovered pitfalls, and explain why they are pitfalls. We need to be clear as to exactly what areas might cause problems or be difficult to get set up correctly. We need to let them know that big complex systems require a lot of knowledge of their moving parts, and that there's no way they're going to absorb it all in a week or two. Heck, I've been here almost five months and I still have areas that I am exploring, mapping and trying to understand. Remember how it feels to be the new tester on the team... then act accordingly. It will save them heartache and it will also save your sanity.

It Works in (X, Y, Z)... Live From SF, it's Selenium Meetup

I had a feeling today would be eventful. Note to self, do not drive down to Palo Alto when there is a meetup in San Francisco. It took me twice as long to make the trek as it would if I had just caught the 5:06 p.m. baby bullet to Millbrae. Still, I made it, with a little time to spare (food was a little delayed which worked immensely to my advantage, and much thanks to La Méditerranée for providing essential victuals and to Lookout Mobile Security for providing the venue).

One of the great things to hear in the introductions is that we spent close to ten minutes hearing from multiple companies with a simple and wonderful message... "we're hiring!". Trust me, after the 2000's, that line never gets old ;).

Tonight's topic is:


Works in (X, Y, Z): Parallel Combination Testing With Selenium, JUnit, and Sauce

David Drake, who is a lead SDET at Dynacron Group will be giving a talk about running tests in parallel using JUnit and Selenium, and utilizing the massive parallelization that Sauce Labs can provide.

Info about David:

David Drake is a lead SDET with nine years of experience in testing and automation, currently working at Dynacron Group, a Seattle consulting company. He maintains their parallel-webtest library for driving tests through Sauce Labs, and spends most of his time designing and using frameworks for performance and functional regression testing.

Selenium has a series of similar  issues. Lots of variables to deal with...

Operating Systems
Browsers
Devices (types and dimensions)
Languages (Localization)

Each one of these would make for a large suite of tests. to cover every possible permutation... close to impossible, at least serially. Still, with a bit of effort, they were able to put together a bunch of csv files to store all of the parameters and the various combinations to text. Messy, hard to read, ugly... yeah, they came to the same conclusion.

They shifted to Typesafe Config as a later step to allow them to create more complex structures that they could map to objects. A big problem came to the fore as they realized that multi-dimensional arrays with linked dependencies made for a really complicated and huge test suites.

To get the system to work they would read in the parameters, create a unique config combination based on a dense muti-dimensional array, convert the resulting configs into JSON, and then run the individual tests based on the config provided. The tests themselves are relatively lean, but the configuration options are huge, and as such, the number of tests run into the hundreds of thousands.

Parallelizing tests is really not hard, especially if you have something like a Grid farm or a Sauce array to work with. However, getting the tests to actually run right... that proved to be the bigger challenge. Yes, you can run multiple tests in parallel on multiple machines, but even in these isolated examples, they still saw odd behavior that wouldn't replicate when the tets were run serially.

Another big challenge with lots of tests running in parallel... how do you keep track of all of them?! The logic that they use is to make sure that descriptive method naming is used, as well as descriptive logging, so that even by looking at the log output of the code, you know what you are running with a minimum of mental parsing time. Had to smile a bit at this because it's very similar to what we are currently doing at Socialtext :).

One aspect to be aware of when talking about JUnit as the driver is that these tests are mostly organized at the class and unit level (makes sense considering, as its name implies, JUnit is a unit testing framework). Thus, many of these parallelization techniques happen with the same class. The real benefit comes when tests are required to be performed over many classes. With multiple classes, plus multiple configuration options, you get into an exponential increase of tests, but with the Sauce infrastructure, you can span out as many servers as you need (which I'll say right now, doing the math, that kinda' freaks me out!).

Areas that they are looking to improve on, and these are still challenges they are trying to deal with, are ways to remember the tested combinations, how to display the tested combinations, and how to parameterize the test runs in a way that utilizes JUnit's framework rather than custom code.

Tools discussed were Parallel Webtest, Typesafe Config, and Sauce method for seeding parallelization runs.

Something that I have to say put a smile on my face tonight. Often, when I hear about a variety of frameworks and the minutiae that goes into it, I often suffer from MEGO when hearing some of these presentations. the past two months have actually helped give me enough information and details that I was able to follow along with all of the details discussed. I'll not pretend I understood every line and statement, but I was able to follow along with at least 90% of it, and that feels really cool! It's also been a great boon that,the more often I come out, the more I retain and feel that I can actually contribute to the conversations. If someone werte to have told me six months ago that I'd be actively writing and looking for tips about how to optimize JUnit to write tests, I would have said you were nuts. I'll consider that a change for the better ;).

WAVEing for Accessibility

Through the past several weeks and months, I've been getting much more familiar with Accessibility testing and some of the areas that we should be aware of when we do this kind of testing. Most of my efforts have been focused on trying to get two primary applications to work with our product. These tools are JAWS (a screen reader for visually impaired users) and Dragon (a speech processing application for those who may have physical limitations working with a standard keyboard and mouse).

As i was trying to look to see if our product was working, much of my time was spent manually using JAWS and Dragon, and then pointing out to the developers where we weren't providing enough information. During this process, the lazy bones in me kept saying "seriously, isn't there something that we can use that can speed this up? Do we really have to listed to or talk to the page to see what it's set up to do?"

Thankfully, the answer is "yes, there is something we can use that can allow us to check accessibility aspects of pages." There are actually several, but one quick, easy and free way is to use WAVE.

What WAVE lets users is quickly analyze areas that might be problematic from an accessibility standpoint, and allow the user to preview them based on the importance of those issues. For example, WAVE did a quick analysis of TESTHEAD and found the following issues:

A more detailed inspection gives us the following:

In addition to errors, it can also show you what you are doing "right" with your pages:

Ever wonder how your site looks when its styling is turned off? In general, we don't like to think about this in this day and age, but it's col to get a quick glimpse... is our site organized in a way that is genuinely useful if all the eye candy disappears?

Curious to know how your site fares in a simple contrast test? For the record, TESTHEAD fares terribly. Much as I like the design, it's giving me pause and making me reconsider my aesthetic conceits.

The examples above use the WAVE site. You can also bring the exploration closer to home with the  WAVE toolbar (currently only available for Firefox). Here's how I look from the "Errors, Features and Alerts" perspective.

Ever wondered where the tab key will take you in your pages? I never used to think about this, but since I work with JAWS regularly, I think about it a lot more. Pretty sad to think that, if you want to highlight my Blog link, you'd need to hit 58 tabs to get there.

Text only mode? Heh, that's actually OK:

Curious as to what all of the possible icons and options mean, as well as a glossary of potential accessibility issues? WAVE's got you covered:

I realize for many of you out there, this may be of very peripheral interest, but these past few months have opened my eyes as to some of the challenges we face when we try to make software accessible to as many users as possible. A lot of the site design prevalent today is very difficult to navigate by using alternative means. If you are not willing, or able, to take a plunge into the world of screen readers and speech recognition directly, but you are curious to see how your site stacks up against some accessibility standards, get WAVE and give it a try. You will learn a lot about your site(s), in ways you never imagined.

Dealing with Lingering Issues

This weekend has been a strange one for me. I went swimming on Friday night with my daughters, not in and of itself a very eventful thing. In the process, I did what I normally do, which was swim a bunch of laps, chase after my daughters and play around a bit in the water with them, and jump a few times off the diving board and high dive. Again, not what anyone would consider a lot of effort or anything close to a big deal.

Unfortunately, I have been "paying for" that outing ever since. My leg has been aching all weekend. Specifically, right at the point where the plate is. It's not too painful to walk, but it's enough of an annoyance that it interferes with sleep and my just hanging around.

I mention this today because, often, we think that we can "fix" things, or that, with time, we will heal up and all will be fine. Sometimes, though, we make changes that have "lingering effects", and those effects lat long after the incident or change. As I get older, I realize that many of the "dents and dings" that I have taken over the years become a little less easy to absorb as I get older. Changes are more difficult to make happen, and healing just takes longer. I chuckled about this a bit as I thought about a recent update that a software manufacturer with a long time product base had gone through, and how some of the changes they had hoped to make that were going to be simple ended up being much more involved, and the user less than thrilled with the changes.

There are some things that we can bounce back easily from, and others that will take a much longer time to recover from, if we really ever do. The most frustrating thing to deal with, at least for me, is the fact that things I used to take for granted now require a lot of thought or some considerable payback if I choose to do them. Our bodies as they age require some more care and focus. we probably shouldn't be surprised that legacy applications tend to behave the same way :).

Weekend Testing Americas: Passing the Baton

Tomorrow will be an interesting day for me, not so much by what I will be doing, but for what I will not be doing.

So far, only once in Weekend Testing Americas history have I physically not been part of a session, and that was because I had just been released from the hospital with a broken leg. Albert Gareev gamely stepped up and took my place for that session, and I'm grateful to him for doing that.

This time, while I have something else I need to do, as I was considering postponing the session until I was available, Justin Rohrman contacted me and said he had a session plan, and wanted to know if he could run with it. I realized that, if I was actually going to have others be facilitators, I had to actually let them facilitate. Thus, rather than wait and postpone until I could be available, I've asked Justin to take the lead and facilitate tomorrows Weekend Testing Americas session completely in my stead. Just as Ajay and Markus had to finally decide I could lead sessions on my own, now is the time to for me to put my faith in Justin and let him lead this one on his own.

I'm sure he'll do fine :).

I shared some thoughts with Justin, and I realized that a lot of the advice I gave him was appropriate to any other testing endeavor, and wasn't just specific to our Weekend Testing environment. With that, I offer the following.

A Facilitator for Weekend Testing events is really responsible for just three things. They need to manage time. They need to articulate the session goals. They need to encourage participants to get involved. That's the core of what we do. The rest (setting up sessions, promoting them, adding people to the Skype chat, typing up an experience report, etc.) that's all mechanics and "busy work". It's important, don't get me wrong, but the first three items really are the most important. Manage the clock. Articulate the goals. Encourage participation and effort. Any test manager in any organization is really responsible for the same things.

Managing time: This is important because we have a two hour block of time. We could do longer, I'm sure, but then it cuts into people's other commitments, and really, we're already asking a lot to get testers to willingly give up part of their weekend as it is (don't get me started on the testers in India that join us at 12:30 a.m. for these sessions... yes, that's after midnight their time. That puts a whole new spin on dedication in my book :) ). Thus, it's vital that we keep a focus on the time that we have, and that we accomplish what we set out to do in that short time period with focus and clarity. That leads to...

Articulate the goals: I remember well a couple of years ago when James Bach attended a session and he, rightly, called me out for our sessions being too vague. Since we had such a short time together, it was vital that we were able to make missions and charters that were clear, specific, and targeted to specific tasks. I was worried that such targeted missions and charters would be too limiting. He proved to me that, in most cases, that's not the case. Even with just testing one simple area of a site, we were able to have a conversation that spanned almost two hours of active dialog, and that was with us looking at just one screen. It wasn't that the screen was any different than any other, but that the goal was focused and specific, so that we were able to discuss and consider the aspects of that one screen without distraction or loss of direction. It was a worthwhile lesson, and one I try to practice still.

Encourage participants: Some people are just not comfortable with talking out loud, even in chat clients. There may be many reasons for this. Some may be novices, some may have language barriers, and some might not want to be seen to "appear the fool". I've learned to never underestimate the terror of that last one. For many, they fear that they will say something foolish, or appear to be "less smart" among their peers. For this purpose, I often put my own ignorance on display in these sessions. Yes, I'm facilitating, but that doesn't mean I'm an expert on the topic. Often, I know less than most of the participants... and that's OK. My goal isn't to be the one saying everything, it's to encourage dialog and learning. I can do that best by asking about things I genuinely don't know, and often, that's a lot. By my doing so, in many cases, it helps others open up and ask questions, too. We're not here because we are experts. We're here because we all can learn from each other, and that's the whole point of Weekend Testing. We learn from each other, sometimes in small ways, sometimes in much larger ways.  As long as we each learn something to bring to our craft, that's what matters.

Tomorrow is a new day. A new facilitator will step up and run with the session, and I will not be there. I do, however, want to encourage all who can be there to do so. Details on tomorrow's session can be found here.

Different Stress, Different Results

I had an interesting chat with a friend last weekend. I say interesting because it was entirely unexpected, and not something I thought I'd be hearing...


"Hey Mike, I'm sorry to have to report to you that my son broke your bindings on the board you loaned him. I bought you a replacement set, though".


Now, I'm happy that my friend replaced the broken bindings, but my first question back to him was "did you save the broken bindings?" He said yes, but I could tell by his voice that he was slightly confused. Wasn't I concerned that his son broke my bindings? Well, sure, but it wasn't a huge surprise. The board that I had loaned him was 15 years old, and was my "rock board". In good shape, but it had been through a lot. The bindings that were on it were likewise about 12 years old, and had been through lots of adventures with me over the years. Was it possible the bindings could break? Sure, it was possible. Still, I had seen or felt nothing to lead me to believe the bindings would fail prior to the trip. I made clear to my friend that I didn't blame him, or his son, for the break. Things happen. I was, however, very interested in trying to see what happened and why it happened, because the tester in me was fascinated. Based on what I know about the board, its vintage, the bindings, and the person who was riding it, I think I have a good theory on what happened.

My friend's son and I have wildly different skill levels. I've been riding for twenty years, and consider myself to be a very proficient rider. By contrast, my friend's son is closer to the novice level. He's still in the process of riding mostly on his heel edge, and not to the level where he can link heel-side and toe-side turns. This puts a lot more stress on parts of the bindings, especially the high-back attachments, for a much longer duration than I would put them through.

Also, my turns do not lean very much into the high-backs themselves. I touch a little bit, but most of my turning comes from my hips and legs, and the board follows along with my movement. In short, I transfer very little actual energy into the bindings themselves. They are there to hold me to the board, not actually wrench the board into place. My friends son, on the other hand, puts a lot of energy into the high-backs to hold himself up and keep himself stable. Additionally, that weight, because he favors heel-side, means that tension is constantly being held while he is actively riding.

The bindings were "high end" for their time, and in this case, high end doesn't really mean "super strong" or "bullet proof". In this case, high end means "high performance as relating to light weight". They were designed to keep the boarder in place if they landed with great torque for very short periods. They are really not designed for long term pressure on the high backs themselves. Different stressors brought out a weakness. In this case, the age of the bindings may have never been an issue for me, but for this other rider, the stresses led to a failure.

Analogous to software testing? Of course there is :). In this case, the parallel is that, as users, we each do things in unique ways, and those unique ways can shield us from issues that other people experience. A beginner puts totally different stresses on a system than a power user does. Some times, the stresses from the power user are the ones that can lead to problems, but occasionally, we find that a beginner may be the one to provide a stress we hadn't considered. It may be inexperience, it may be favoring a particular way of doing things, but if we don't consider both ranges of stressors, we may be optimizing one area while leaving another area vulnerable. This is where different personas can be vital. They make us reconsider who we are and what we are doing, and often, they let us see a world we personally would never consider.

Creatures of Habit

In some way, shape of form, we are all creatures of habit. We learn them, we try to live with them (in the positive cases) or we try really hard to change them (in the not so positive cases). One thing is for sure, if we do not actually create an environment where our habits will thrive, we will inevitably make an environment where our habits will fester. Sound like double talk? It isn't, really.

One of the things in the past few weeks that I did while preparing for our exchange students to be with us was that I shifted off the train and into my car. I wanted to make sure I had flexibility, and also to make sure that, should the train be delayed, I wouldn't be stuck when I was needed elsewhere (in fact, it was a large train delay one morning that prompted my moving to the car in the first place). What I later realized was that a lot of my momentum on other projects really depended on that "train time".  My Selenium practicum, my blog posts, a lot of my semi casual reading, was done on the train. For two and a half weeks, I broke the rhythm, and in the process, I also broke a number of other rhythms, and they cascaded out into my not doing things I wanted to do or needed to do.

When I'm taking the train, I have a number of transitional time periods. It's a process. From the time that I park when I park the car at the lot, walk up to the platform, sit or stand to wait for the train, get on the train, sit on the train until I reach my destination, get up and get off, walk to work, and then repeat the process on the way back… all told, that time works out to about eighty minutes. Those are eighty minutes where I am not physically engaged in the process of driving, and as such, I can actually let my mind roam free and think of other things, and often physically do other things. I can write, I can sleep, I can daydream, if I feel so inclined. I can't do any of that when I drive. For that time, even if it proves to be less total time en route, I am engaged in the task of driving. Even if I were to bring a recording device or some other auditory form of time use/learning, I'd have to do a second pass to capture ideas, take notes, write something, etc.

One of the things I've told my kids over the years, and I've heard articulated in other ways, is that it is easier to make a habit if you can associate it with something else that you do. If you know that you need to eat at a certain time, that may be a good time to whip out some book you want to get through. If you are going to be checking out Facebook, make a point of doing so while you are on an exercise bike or treadmill. Corny? Maybe, but it just might help you spend more time exercising, or less time on Facebook, whatever is the intended goal ;).

While combining efforts can be big motivators to doing more or creating new habits, changing to activities where you have to limit what you do can make you fall out of habits. Great if it's a negative habit, not so great if it's something you really want to be doing but aren't. Too often, we end up not doing the things that are important. Instead we end up doing the things that are urgent, or if we don't want to be that dramatic, then "pressing". When we deliberately structure our days to take us out of a mode where everything is pressing, then we can allow good habits to flourish. Likewise, if we succumb to doing something to gain a few minutes because everything is pressing, we may lose more than we actually gain.