A hammer builds, or not?

Last night, while i was browsing the latest tweets, i noticed there was a discussion going on about the difference in compilers and debuggers. Two of the comments made by Michael Bolton (@michaelbolton) were:

@testalways Debuggers don’t debug any more than compilers write programs, any more than hammers build houses.
@QualityFrog @testalways @AGareev A thing doesn’t act like a tool until an actor, a person, puts it into action.

I continued reading the tweets on this topic, until I read the following tweet by James Bach (@jamesmarcusbach):

@michaelbolton debuggers don’t ever perform any debugging. But hammers and compilers really do build and build, respectively.

After reading this, I thought: “Well, James, a hammer is a tool. It’s a dead object. It can do anything. So it can’t build”. Now, I could have held my mouth shut. But when I disagree with a comment, there is an incredible urge inside me which says: “mingle, mingle, mingle!”. So I did. I mingled, without asking (which some might consider as rude. But I like discussions. They help me learn. They help me understand. They educate me. A good discussion helps me to see things from different perspectives. At least, I hope so).

It’s the person handling the hammer that creates the pattern of a house. A hammer is not required to build a house. There are many types of houses which are entirely made by hand. Just imagine the clay houses in some 3rd world countries. So I replied to James:

@jamesmarcusbach How does a hammer build? It’s not the hammer that creates the pattern of a house. /cc @michaelbolton

It’s the person handling the hammer that creates the pattern of a house. A hammer is not required to build a house. There are many types of houses which are entirely made by hand. Just imagine the clay houses in some 3rd world countries. And then I received James reaction:

@MichelKraaij don’t ask silly questions.

What, whut? Silly? My question wasn’t intended silly. It was a dead serious question. I was asking how a hammer builds. In my perception the hammer doesn’t build. It’s a tool. It is the person handling the hammer that builds. But did I really ask a silly question? Or did James interpret my question as silly? Maybe I was asking something obvious, because to him a hammer actually builds? Then indeed, it might have looked like a silly question. Maybe I’m just misinterpreting something. Or he is. Words can get misinterpreted very easily. Let’s continue. There is only one way to clarify all of this. Respond:

@jamesmarcusbach It might have sound silly, indeed. Maybe just as silly as saying that hammers do build.

Yes, my question had a little sarcastic undertone. And I chose to answer using his own words. What I didn’t expect was James’s response:

@MichelKraaij instead of insulting me, use your brain. Come on, man. Don’t play dumb.
@MichelKraaij I could answer your question, but you already know the answer. Don’t waste my time, please.

Huh? What happened here? My tweet wasn’t meant insulting?! To me, the word silly means “funny” or “humorous” in a bit of sarcastic way. Did I make a bad translation here? Let’s look it up. Oh wait, the word “silly” has several meanings in English. And some of them can be interpreted as insulting indeed! Damnit, that’s why I prefer to speak face-to-face instead of *just* chatting. So many emotions don’t get transferred when sending a tweet. Something went terrible awry here. Why would I waste the time of someone whose opinion I value? Let’s ask for some clarification, because he really lost me here…

@jamesmarcusbach Then pls help me understand “But hammers & compilers rlly do build & build, respectively”, b/c clearly i’m not getting it.

A short 15 minutes later, James responds:

@MichelKraaij I’ve taken you close enough to the solution. Get up and think, now.

This one sounds a bit more challenging. After all, I consider James (and Michael) to be my mentors. So I value their responses. Especially when they sound challenging. Now, where was I. Did I really miss something?

In the meantime, I see a tweet from Peter Houghton (@petehoughton) pass by:

@MichelKraaij I think it’s along the lines of debugging is a cognitive (exploratory) activity. Building is more mechanical, formulaic.

Yes, this is true. Debugging is about exploring and about revealing, which can be done either manually or with support of tools. So this is a cognitive activity, indeed. In addition, a potential bug has to be interpreted by a person, again, a cognitive activity. So I respond to Pete:

@pete_houghton I think of building like testing. A set of activities, some of these activities supported by tools, with a purpose.

Okay, back on topic of the misinterpreted sentence. Have I misinterpreted it? Wait, is he actually talking about a “hammer”. Like, the tool which I use to hit my thumb? Or is he referring to something else? Am I missing something? MC Hammer? Nah! A different tool, called “Hammer”? Let’s Google. Well, yeah, there actually is one! It’s a mapping tool by Valve. No, I don’t see James as the type who fiddles around with maps for online gaming (actually, I used to do that a few years back, when I played CounterStrike. So I actually knew the program!). I continue to ponder… In the meantime, I receive a reaction from James:

@MichelKraaij have you figured it out yet?

No, actually I don’t. I start questioning my own judgment. Am I actually dumb? Is he right? Am I missing something that obvious? Or…. am I misinterpreting words in the sentence? Let’s ask:

@jamesmarcusbach No, not yet. But i do want to ask a question (yes, it might sound silly). Are we talking about this?: http://bit.ly/hv9mCH

Oh, drat, I used “silly” again. Well, message has been sent. Nothing I can do about it anymore. And then it remains silent for a while… Maybe this was really too insulting?

Suddenly Stephen J. Hill (@stephen_J_Hill) responds:

@MichelKraaij @jamesmarcusbach Hammers & compilers are both _tools_ used directly in building. Debuggers highlight pattern for others to id.

Well yes! I totally agree. Nevertheless, you’re saying what I was thinking…it’s a tool! (And my brain fills in: “It doesn’t build on its own!”). After a while, James responds:

@Stephen_J_Hill It’s true that the hammer and compiler are tools used in building, however, they are also themselves actually building.
@Stephen_J_Hill You have to ask yourself: what does it mean to build something?

Okay, he addresses the question to Stephen, but I take on the challenge to answer the question, since I has on my mind for quite a few hours now. I answer:

@jamesmarcusbach @Stephen_J_Hill I suppose it means to structure/merge parts (e.g. materials/pieces of code) in a certain way.

Within a few minutes James responds:

@MichelKraaij To connect parts together into a greater whole is a kind of building. Hammers and compilers both do that.

Yes, hammers do connect parts together into a greater whole. But if I place a hammer on the floor, nothing gets connected. Michael mentioned this in his tweet, stated in the beginning of this blog post. Nevertheless, a car also drives. My eyes also see. But, they all need additional components. They need components, like my brain, to be able to understand the convert light. Only then, it sees. (There are people can look, but do not see anything. The light doesn’t get interpreted, either by the eye or by the brain. These people don’t see). I consider building as a system. It needs certain components to function. Yes, you can take away components. But that destroys the system. So I answer:

@jamesmarcusbach Nevertheless, neither are mandatory for building. Also, they will not build by themselves.

James responds:

@MichelKraaij Neither of those elements are required to make what I said true and relevant.
@MichelKraaij A debugger is not a debugger, but a hammer and compiler both build.

I agree with the first part. A debugger doesn’t do any debugging. All the bugs remain, until they get fixed. This isn’t something a debugger (tool) does. But to me, building is an activity. And a hammer is a tool. So, a hammer can become a building tool. It’s still a tool, but now used in the activity of building. So I respond:

@jamesmarcusbach I think of building as an activity. Yes, a tool can become a building tool. But it’s the combination that builds.

Even my hands are tools. They can be put to use to help me, my consciousness, to build things. They can be put to use for a lot of things. Like transferring my thoughts into movement, which in turn makes letters appear in this blog post (thanks for technology!). James responds:

@MichelKraaij Building is an activity. It’s an activity that is performed by hammers and compilers.

By now it’s almost midnight. I head over to bed, confused about this conversation. In bed I ponder about “action causes reaction”. A hammer in motion has an effect on other objects, like nails. Is he thinking this? Well, in that case it’s the action from the hammer that builds, yes. In that context he might be right. But to me this isn’t the complete context. It’s “a” context. I’m thinking more in terms of the action from the person handling the hammer which in turn moves the hammer. Still confused, I fall asleep….

A rather long blog post this time. But I felt the need to put my thoughts on (digitized) “paper”. This is my opinion. It might not be yours. However, I do am interested in yours. Feel free to give your opinion about this discussion.

Advertisement

Becoming a science nerd…

Sometimes joining platforms like Twitter can lead to highly unexpected, but really great opportunities. One of those opportunities is being mentored by someone who I consider to be one of the lead experts in testing: Michael Bolton.

I’m a professional tester for quite a few years. But lately I had the feeling that something was “off”. In the Netherlands most approaches focus on organizing testing. People came accustomed with getting scripted test cases, mostly based on formal test design techniques. Yet, these artifacts and techniques are tools and require an immense amount of time. Customer quality satisfaction often became heavily overshadowed by the high financial investment that comes with testing a product this way. This didn’t quite suite the way i want to be of service to my clients.

My question: Is there an approach which sustains, or maybe even elevating the satisfaction of my customers, without having negative impact on my services?

Well, I found out there is! Just a few months after i first came in contact with Michael Bolton i participated in the Rapid Software Testing course. The course was held in Amsterdam in juli 2010.

Some of the key elements why i personally enjoyed this course:

• high level of interactivity;
• safe environment to succeed, but especially to fail (which is key factor for learning);
• very cognitively engaging!;
• hands-on experience;

Some of the things i took home with me and now help me on daily basis:

• heuristics. Not that I didn’t apply them before the course, but now that I’m aware of them I tend to utilize them better.
• models. We all creat models in our mind. During the course I became more aware that my personal models are also fallible. I now actively question my models, just like I would question every other phisical artifact which describes a product.
• oracles. They help me to recognize a problem. This course made me aware of the many oracles that I took for granted (or took as a “fact”).
• recognizing and managing bias. We have so many that we’re unaware of. Many which influence our daily behavior.

This is just the tip of the iceberg. There is so much more to talk about. Take my advice, take a peek at the RST slides, which are freely available, and you know what I mean: http://www.satisfice.com/rst.pdf

Best of all… the course didn’t stop after these three days! Both Michael and James offered their assistance whenever you feel stuck or need reflection of ideas…

One of the best things this course and all the conversations on Twitter instignated is my interest for science. Especially cognitive science. This new experience resulted in me actually reading my first book. Yes, at age of 33 i started reading. Ofcourse, i read before. But that was more to kill time. Now I really read out of interest. Actually, the first book I ever bought online is “Secrets of a Buccanneer Scholar” by James Bach. When I was reading it, I thought “hey, this is my life story!”… But I will blog about that some other time. Nevertheless, my book collection is still growing!…

Michael, thank you for enlightening my thoughts about testing. Back then, during the course, and still now. Thanks for making me a science nerd instead of ‘just’ a test nerd 😉

PS. I noticed that i didn’t even mentioned “Exploratory Testing” ones. Well, to me it’s more important about why, when and how you do it than how you call it 😉

Responding to the "Thread-Based Test Management" introduction

First of all, James Bach and Jon Bach, thank you for you discussion-worthy blog posts, here and here. It’s time to wake up the testing scene and your blog posts keep on doing this. Chapeau!

Because i have a few goals of my own, where one is to enhance my blog writing skills, i decided to write my reaction to the recently introduced “Thread-Based Test Management” blog posts on my own weblog (instead of commenting on Twitter). During the writing of this post, i also discovered something new. The translation part of my brain doesn’t seem to keep up with the story telling part of my brain, resulting in having difficulties writing down in English what i want to say. So i tried a heuristic which i’m going to name “simplifying before clarifying“. Basically it’s: write down what you have to say in your native language, which should give you enough time to think everything through, discussing with yourself and statements by others, and translate them afterwards. Very basic, but it seems highly effective for me!

Jon and James…As a reply to the introduction of T(B)TM, i posted the following comment on Twitter:
“@jbtestpilot @jamesmarcusbach Hmm, I’m having a bit of a “huh?-really?-so?” feeling about T(B)TM. Can’t put my finger on it, yet. Pondering…“

A little while Jon responded. I even discussed it a bit with Jon. A very useful discussion, but it deviated a bit from the issue i was pondering about. Yes, a new thread 😉

James, you answered:
“@MichelKraaij I tried to answer the huh/really/so questions in my entry. What did I miss?“

Because a good response takes time to work up, i didn’t immediately respond on Twitter, but write it down in this blog post.

About TBTM. Maybe I’m missing one or two points, or maybe I’m off totally. I’m hoping you guys can help me out a bit. When I’m analyzing your blog post, i read the following. I see a mocked-up example:

Test Facilities

• Power meter calibration method
• Backup test jig validation
• Create standard test images

Test Strategy

• Accuracy Testing
• Sampling strategy
• Preliminary-testing
• Log file analysis program

What i see here is a to-do list. A list with topics hierarchical arranged. Yes, a list like this does look like a thread. Defining threads in a to-do list does have benefits over a list with no hierarchy. You are able to keep a clear overview of the tasks that belong together. I personally even add “estimated-times-required” per item. For me, creating such a list gives advantage during some chaotic running periods (like when I’m testing in two or three project simultaneously). But the concept itself is nothing new. I do it almost every day… And as i read, so do you…

Next, pick up these issues and work them off, preferably in their hierarchical order, through use of time boxes. In some cases you first need to pick up an item from a different thread, because they depend on each other. But nevertheless, you work through the list in a hierarchical order, until you finish a complete task. By setting time boxes you are able to predefine a daily schedule. At the end of the day you have the honorable job of checking off several accomplished items and leave home with a smile on your face.

For me, TBTM seems actually nothing more than a hierarchical to-do list which is finished point by point, through time-boxing. Of course you can nominate this as a methodical approach and give it a name, but I see nothing more than two subjects that I already do in my daily work:

1. Creating a hierarchical drawn, checklist-like, to-do list;
2. Carrying out items from this to-do list, by use of time boxes;

To address James’s initial question: “What did i miss“. Maybe he didn’t miss anything. In fact, I even think that James and Jon thought it through very well. The story is clear and complete. But to me it isn’t new. Or did i miss something myself?

Being cognitively engaged

Last night i was hunting for interesting testing blogpostings… again. There are so many people telling the most interesting and compelling stories, you could spend days on reading them. But last night one blog caught my attention. Well, actually it wasn’t really a blog. It was a question asked by a developer, who calls him-/herself “Anonymous Coward”. (with respect to all my female blog readers, lets assume this person is a “he”. It will make blogging easier ;)). He stated the following:

“…one thing has always kept me back from being able to write the best software I possibly can: testing. I consider testing to be the absolute bane of my existence. It is so boring and un-stimulating that I usually skip it entirely, pass the testing off to someone else, or even worse, if I absolutely have to test, I do a very poor job at it.“

To me, testing is anything but boring or un-stimulating. It’s my hobby and my passion. So i continued reading:

“I know I’m not that lazy, as I can spend hours on end writing software, but there’s something about testing that makes my mind constantly wanted to wander off and think about something else.“

I was thinking: “Lazy? You’re not lazy! You are just not cognitive engaged anymore!”. Testing is challenging! Testing is about solving difficult puzzles. Testing is about boldly going where no man has gone before! Okay, maybe that’s a bit over the top, but you get the point…

Is this testing, what he’s doing? Someone just told him to *check* his code for errors. So he’s writing some cases to prove his code matches a specific result. The result of the check. To me this isn’t testing. There is no challenge in this. He already knows what results to expect. He already knows the answers to all the questions asked. The cognitive engagement, which was there when he designed and coded everything, is long gone. I can completely understand that his mind is constantly wandering off.

What if the developer took a different approach? What if the developer tried something which depends more on creatively solving puzzles, having more challenges or at least bring the boring part to a bare minimum? Would something like Test Driven Development be more challenging than ‘old-fashion” development with a standard unit-testing time box?

Any thoughts?

Revising the definition of quality

Today i was pondering on one of the definitions which originates from Jerry Weinberg, but was expanded by James Bach. The definition of “Quality” goes:

“Quality is value to some person(s) who matter“

Now, i do like this statement. It’s not as complex as many other definitions on quality. It’s easy to explain to someone. However, like i’m doing now, it’s still debated by many bloggers. It’s time i started my first blogpost and address what’s on my mind, instead of trying to squeeze everything in a 140 character Twitter message.

To me, there are some vital components missing in this definition. For this blogpost i want to address at least two of these components which, i think, add more value to this definition:

1. Context
2. What is valued

The value according to something/someone is depending on the actual context. We need a context to actually value something. While modeling a context, we are all making a whole load of assumptions around the context that you probably didn’t realize. When something alters this modeled context, the value to some person(s) might also be altered.
In addition, in his blog Markus Gärtner added the time element to the definition of quality. I agree with him that the time factor is also important for quality. But basically this is also an element related to the context.

Next, we can’t value thin air (well, actually we can, but metaphorically speaking). The value has to apply to something or someone. What is/are the person(s) that matter valuing? Are they valuing a specific piece of software? Are they valuing someone’s opinion? The “what” isn’t addressed in this definition.

My suggestion for an improved definition of quality:

 “Quality is contextual value of something or someone, to some person(s) who matter“

Any additional thoughts are welcome. Feel free to reply…