The Table Saw Heuristic

AKA Bootstrapping

This is my father’s table saw.

I inherited it when he passed away into memory eternal in 2017. For a couple of years it sat in my sister’s garage before I could arrange to transport it and store it in my garage. It’s a beast of a machine weighing in somewhere, I would guess, around 600 lbs. It sat in the corner of my garage for another year and a half, daring me to use it. But quite frankly it scared the daylights out of me. As a teenager I had used it a few times under my father’s watchful eye, the last time of which I nearly lost a finger. Well, I lost a thin kerf’s width off the end of my middle finger on my left hand. It wasn’t terribly serious. It didn’t require a trip to the emergency room and needed little more than a good cleaning and a bandage wrap for a couple of weeks. I have no lasting damage from it except for the lingering deep-seated fear of this monster I have rolling around in the recesses of my psyche.

I understood, from having observed my father for years, generally how it works. But when it came into my possession it had been partially disassembled for ease of transportation. And it came with an assortment of attachments, fences, jigs, and blades of different sorts, none of which I really understood. I wasn’t even sure how to put it back together again. It was daunting and confusing and scary. So there it sat in the corner, taunting me.

But still, I want to use it. I want to master it. I want to use it to make beautiful furniture like my father did.

Entryway table made by my father.

Enter the Bootstrap Heuristic

Anything we encounter which we want to master will of necessity start out confusing, bewildering, chaotic, and perhaps a little bit (or a lot) scary. But this is a temporary thing and can be overcome. Knowing that this is the case allowed me to embrace my fear and confusion and just find a place to start.

I needed first to put it back together. So I pulled it away from the wall, laid out all the parts, and began to familiarize myself with both the machine and the parts. I reasoned about each of the parts, where it might go, what its purpose might be, digging into the recesses of my memory to try and remember how it looked when it was put together. I tried to put things together, stepped back, and looked at it. No, that isn’t right. I think it needs to go this way. I thought I could benefit from some documentation, so I looked up the model number and did an Internet search. That was a bust. It was built in 1969. No one has documentation for that thing. I did find a manual on E-bay for a similar machine but not exactly the same one. Besides, I have a sneaking suspicion this has been modified by my father to better suit his needs. So back to experimenting.

Another couple of hours of tinkering and I finally had it put back together and was reasonably sure I had gotten it right. I didn’t have any bolts or nuts left over anyway. That seemed like a good sign. I went to plug it in and then discovered that it was not a typical plug.

I’m not much of an electrician. I was once again very confused. Do they make adapters? Will I have to wire a special outlet? Why is this even different? Something about the motor?

Back to the Internet. I had more luck this time. I learned what I needed to know fairly quickly and found the appropriate extension cord on Amazon for a few bucks. Problem solved.

The next weekend rolled around and I now had everything I needed to finally try it out. So with some trepidation and fear I flipped the switch and was greeted with the all too familiar (and very loud) sound of this beast roaring to life with the blade whirring along at a brisk 3450 RPMs. Success!

At this point, I now knew a lot more about this machine than when I started. I was more comfortable with it. I understood how it was put together. But that is not the same as using it and producing something usable and beautiful. It is a tool for cutting wood. So I grabbed some scrap lumber I had laying around and tried a few cuts. It worked. Just like I remembered. Although it seemed to labor under the small load of a 2x4 and I knew that was not right. I conjectured that the blade was dull. It just needed to be sharpened. The fact that I knew it could be sharpened and not just replaced came from the not so distant memory of my father, in late stages of Parkinson’s, obsessing about sharpening his saw blades. At that point he could barely walk or hold his utensils for meals. But he was convinced he needed to sharpen those blades right now! So much so that he purchased a sharpening kit when no one was looking (thanks Amazon) and then kept badgering everyone who came over to help him set it up so he could get to work.

Armed with this knowledge, YouTube was my next stop. Surely there are some experts that have explained in enough careful detail how I can sharpen those blades. The first thing I learned is that maybe it didn’t need to be sharpened just cleaned. Resin from wood tends to collect along the edges of table saw blades and makes them sticky. Who knew? I learned how to examine the blades and make judgments about what needed to be done.

So the next weekend I pulled the blade out and examined it, along with the three other blades I had. I quickly determined that cleaning and sharpening, while clearly necessary, may not be enough. Every one of the blades had multiple broken and damaged teeth. Did you know those teeth can be repaired depending on the type and extent of damage? But now I had to make a determination about whether I should get the blades repaired or just buy new ones. I needed an expert’s opinion on this.

I found one place within 50 miles of me that sharpens and repairs table saw blades. I will have to make trip down there sometime this fall and see what the verdict is. But for now I am stuck with some blades that might be alright for an occasional rough cut, but no fine woodwork is going to happen with this machine until the blade situation is rectified.

I still had some other questions floating around in my head about the motor and maintenance. Did it need to be oiled or greased? And the depth and angle adjustment cranks were stiff and hard to move. As providence would have it, my older brother, who is himself an extremely gifted master craftsman (really, click the link and take a look) and who had used this very machine extensively over the last two decades came to visit a couple of weeks ago. Perfect! I asked him all my questions. He gave me the answers I needed and some I didn’t know I needed. I was able, with his guidance, to tighten the belt, grease the tracks for the depth and angle gears, and set my mind at ease about the maintenance of this family treasure.

I’m 6 months in now from when I started this journey. I still have not built anything with this table saw. Well, I cut a few 2x4s for some garage shelves; I guess that counts. I still need to rectify the blade situation. But it no longer scares me. I am no longer bewildered by it. Now I am in a position to start learning how to use it to make useful and beautiful stuff. I have made it through the initial cycle of bootstrapping and am ready for the next. Carpentry.

I thought this blog was about testing?

Why, yes! Yes it is. I tell this story because it illustrates some things that have application to testing. I’ve been a consultant for the past five and a half years. In a sense I have been bootstrapping constantly that whole time. Every new contract was a disorienting, bewildering, and often scary transition. I did that 7 times in 5 years. And in those 5 years, in most cases, I never got to make any furniture. About the time I got over bootstrapping, I was moving on to the next gig. That changes tomorrow when I start a full time position as a QA Strategist for a small healthcare company. But I will have to bootstrap one more time. So I will take the lessons from my Dad’s table saw with me.

Laying out the pieces

When I first go into a new testing project I start by laying out all the pieces to try and start making sense of the domain. This includes but is not limited to creating a functional outline, list, and/or mind map of the product. Reviewing or creating data flow, architecture, and object model diagrams. I learn about how the product is built, packaged, and deployed. I try to dig up and review any existing documentation: user manuals, wikis/confluence pages describing the business domain, requirement documents, or user stories from recent releases. Most companies have training videos squirreled away somewhere. I find those particularly helpful because they are usually given by some domain expert. But I always keep in mind that such documentation will always be incomplete, out of date, or just down right wrong. Things change, like my father’s customizations to the table saw, and those docs may not accurately reflect the current reality. But they can give me some good context.

Ultimately though, I want to turn it on and cut some wood. I want to get my hands on the product and play with it. I can learn a lot about a piece of software in an hour or two of just playing around. As I play and explore the product, I make a list of questions that come up to track down later. I make notes about things that I want to explore more formally.

Check with the experts

I also want to talk to the people that know the most about the product. I prefer to start with the end users if I can get access to them. I want to know from their perspective what problem this software is trying to solve for them and how well it is doing that. Quality is value to someone. So I want to know what the stakeholders consider valuable and what they consider not so valuable.

I also like to talk to support people. They are the ones on the front lines that know all the pain points. A lot of good testers find their way into testing via the support route because I think it offers a unique view into the product that lends itself to cultivating good testers. Reviewing support-ticket trends can also be very enlightening about areas where quality may be lacking in the product.

And I like to talk to the OG: those developers, architects, and managers who have been around the longest. Even that CTO who built the first version of the product. The history of the product can be a gold mine when it comes to understanding quality issues. I like to understand how we got to where we are today.

And of course I talk to the team building and maintaining the product. What is hard to maintain? What part of the code do they fear touching because of its fragility? How have they been testing the product?

Never stop learning

I have learned through painful experience that you should never think you have it all figured out. Never stop learning. Don’t be surprised when things are not what you expect. Always check your bias by sharing what you are learning with others and getting their feedback. The well from which quality springs is a deep and cavernous one. There are layers upon layers of things to be explored. I have started deliberately collecting heuristics to remind me of things to dig into and learn about. With each passing release I try to look for blind spots: things I haven’t considered; things that didn’t go so well last time. Then I explore ways of leaning into to those discoveries in service of better testing.

The Table Saw heuristic

While most of the testing world knows this as the bootstrap heuristic, it will, for me from now on, be known as the table saw heuristic. I think it captures the sense of dread and fear that often accompanies the confusion and bewilderment of a new endeavor better than “bootstrapping” does. And for me that’s important because fear can be paralyzing. But knowing it is a natural part of taking on any new worthwhile activity empowers me to get started. Having other heuristics to help me get over the hump is also useful.

Over the next few months, as I take on the table saw of my new role, I hope to bring you along on the journey. I’ll share some more of the heuristics and tactics I use as I build a quality strategy with my new team. Maybe, just maybe, I can keep all my fingers in the process.