In various posts I’ve tried to show how I believe testers can invent solutions to problems they are encountering. These solutions do not always have to be tool-based in nature. Sometimes you are presenting a new way of thinking about processes, sometimes you are reframing problems, sometimes you a providing a hopeful vision, sometimes you are in fact coming up with ad-hoc tools, and sometimes you are coming up with new techniques. At the core of this, however, is thinking about problems and thinking about solutions. It’s about being an inventor.
Anyone who has gone through at least one geometry class has probably been shown the Necker Cube but, just in case, here’s the concept:
After being shown this students will then be asked:
Is the dot located in the lower left rear of the cube or in the lower left front of the cube?
Assuming you have relatively normal vision and if the spatial portions of your brain are working correctly, the cube can appear to “flip” so that the dot is sometimes “inside” and sometimes “outside” the cube. Or you can think of it in terms of the front “wall” of the cube being either to the upper right or to the lower left.
What’s sometimes not described is why this effect is happening and why it matters. The visual shift happens because you are looking at a three-dimensional object that has been rendered as a two-dimensional object. Reference cues in the drawing allow your brain to visualize the three-dimensional aspects of the cube. Even though your mind is attempting to fill in those missing details, the two-dimensional drawing does not give enough information for your visual processing centers to know exactly which face of the cube is at the front. Or, rather, it’s possible for you to receive conflicting views and thus you have a shift in perception.
How you probably learned this in geometry — or, alternatively, cognitive psychology — is that the cube is depicted as a wireframe in an orthographic projection. That means the perspective clues regarding the cube’s orientation are lost.
I like the Necker Cube concept because it tells me:
- Anything I see is an approximation by my visual system. The visual system comes up with a hypothesis that the cube is at one orientation. Yet further viewing then indicates to the visual system that (for some reason) another hypothesis must be asserted: a different orientation.
- I never see both orientations together because my visual system must decide which hypothesis is favored. Once one view is favored, that one becomes reality. This is a heuristic; a rule of thumb. What the visual system sees is what is defined as reality. (Until it changes.)
- Both cubes are equally compatible with the two dimensional data on my retina, so my brain has no problem alternating between them. Neither is more correct than the other. Two views of the same truth. I can flip between one and the other and still have the same idea.
Think about the first point in terms of how people view things like a person’s motivations, or the dynamics of a team, or the use of a process, or their use in picking different programming languages or testing tools. Sometimes our viewpoints shift.
Think about the second point in terms of how sometimes we can define our “reality” and assume that’s how it must be and there can be no other way — even though there often is one starting us right in the face.
Think about the third point in terms of being able to hold what may seem to be entirely incompatible visions of something at the same time. Think about that in terms of managers who need to adhere to organizational process but who also want to accommodate individual practice.
The Necker Cube model suggests that the two ways of seeing are equally as good. After all, one view is not more accurate than the other. They are simply different views of the same underlying truth. Think about that. It’s actually a powerful message — and not one that’s often talked about in relation to the Necker Cube. So, to me, the Necker Cube represents a change in vision. Richard Dawkins had this to say:
Rather than propose a new theory or unearth some a new fact, often the most important contribution a scientist can make is to discover a new way of seeing old theories or facts.
And that, my friends, is what inventors often do: they don’t so much create out of whole cloth as they do rearrange existing parts. They see things differently. They have a slightly different vision or are able to maintain two shifts in vision. Consider:
- In science, a change of vision can, at its best, achieve something loftier than a theory; it can usher in a climate of thinking, in which many exciting and testable theories are born and various facts laid out for inspection.
- In art, a change of vision can, at its best, achieve something loftier than a novelty; it can usher in a climate of new perspective, in which many exciting and useful techniques are born and various means of presentation laid out for inspection.
If you saw my thoughts on testing as art and science, then you’ll start to see here where the art part comes into play.
The Necker Cube concept almost gets to what I’m talking about in that it captures the idea of a flip in vision. What the Necker Cube does not do is take that idea anywhere because the consequences of that flip don’t necessarily matter. The Necker Cube can still be relegated to a “visual trick.”
Still, that’s seeing differently. That’s one component of an inventor. But what about the next component? What about thinking differently? Albert Szent-Gyorgyi somewhat mirrored Dawkins’ earlier statement when he said,
Discovery consists of looking at the same thing as everyone else does and thinking something different.
In order to think differently, you have to see differently. But in true paradoxical form, in order to see differently you have to think differently in the first place. I’ll be honest: I don’t find many testers that embody this paradox. If I had to point to one thing I want a tester to show me during an interview is a demonstrable ability to see and think differently from others. I do firmly believe that the major thinking battle of any test team is the recognition that it needs to become a team of inventors.
This points directly to the kind of skill set you want in a tester because invention is a word used for the products of a nimble mind. Inventors don’t create in the categorical sense. Strictly speaking, creation is to make something where there was absolutely nothing. Inventors, by contrast, use what’s at hand and then they add something of their own mental skills. What they produce could be new ways of recombining old elements or making tiny little improvements in existing elements. Even if you are creating your own test management system or your own automated tools, chances are that you are reusing a lot of work that has come before you.
I already indicated that inventors may provide an entirely new way of looking at things by seeing differently. So by thinking differently, they have allowed themselves and others to see differently as well because the most effective inventors encode their vision in what they invent. Think about the number of test tools you may have seen where you wondered “Why did they write it to do that?” or a process you had to be part of where people said “Why in the world do we do things this way?” Sometimes you look at tools or process and it doesn’t seem like there was any sort of overall vision to them beyond slapping together some parts and hoping it would work. That kind of cognitive friction, when using a tool or a process, is often an indication that a mindset of effective and efficient invention was not present.
I think that the really good inventors do this “seeing and thinking differently” with a high degree of efficiency and with as little flash as possible. As Donald Akenson put it in his book Surpassing Wonder:
One thinks with admiration of the medieval inventor who first whittled from a piece of oak the eccentric cam, and attached it to the rim of a wagon wheel, thereby permitting the translation of rotary motion to linear force; on that elegant simplicity hangs all modern mechanical transportation.
Very little flash, but quite a bit of efficiency.
I also think it’s important to keep in mind that between the merely good inventor and the truly effective inventor there’s a line. If I can be granted some literary license, inventors tread between the Scylla of being way ahead of their time and the Charybdis of being totally irrelevant. Let’s assuming someone isn’t being totally irrelevant for now. Even with that out of the way, there’s very little that’s more useless than a physical invention that’s way ahead of its time or a cultural invention that’s way ahead of its audience.
Think of Alexander Bain who invented the perfectly workable facsimile machine — around 1843. Think of Edouard Belin who did similar work along those same lines in 1925. Or think of Frank Sprague who invented the first electric railway — back in 1888. These people knew what it meant to be ahead of their time. I doubt you could say they were totally irrelevant, although I suppose that’s a viewpoint thing.
So let’s bring this around to test teams.
The thinking battles will be the extent to which the people working within the test team invent products and services to fit the context of the business, particularly in terms of its bottom line and its competitive advantage. However, there needs to be some checks and balances such that what gets invented — the products created, the services offered — are in line with the culture of the company and in terms of what keeps the company profitable.
A good example here might be automated testing tools. I’ve seen some testers who spent most of their time designing the next great test automated framework. Yet, while that framework could do the job needed, it took a long time to build. In fact, it never really seemed to get to a working state. I’m not talking “finished” here; just to a state where it can be used by people. In the meantime, much simpler solutions were not being utilized such that testing work wasn’t being done in the most effective manner. The framework being developed was fantastic; a true wonder of coding prowess; one that I wept to behold and measure my inadequacies next to. Yet, still, the application wasn’t being tested in an automated fashion and, darn it, we really wanted that in our lifetime.
Might the framework have been a necessary product or service? Yes, ultimately. But the question is whether the product could have been introduced quicker with just enough invention to make it useful for immediate purposes. In other words, maybe a framework isn’t quite what was needed. Or at least maybe a less amazing framework would have been okay. Would it have been perfect? Nope. But it would have been there; and it would have been used.
Here we had an invention ahead of its time. It simply couldn’t be used because it was too busy solving problems that we might not even have and was too busy striving for some ideal state of perfection. It tried to be a non-moving target in an arena where moving targets are not just the norm but almost a necessity.
As another example, I’m an advocate of the concept of spec workshops. I believe they are a fundamentally important technique in the drive to improve communication and streamline collaboration. Yet I’ve been in environments where it’s near impossible to get people to buy into the concept, even after it is explained and even after it is tried. The rejection is not because these people are too stupid to know what’s good for them. Rather, the appropriate context simply has not been put in place yet such that people believe in the need for the concept. Intellectually, they get it. Emotionally, they’re not buying it. This is an example where you can have an invention ahead of its audience.
So what does a team of inventors do in these cases?
Well, on the one hand, you strive to invent what’s needed. And what’s needed is what will solve immediate problems and show tangible benefits. When you have a team that’s not doing this, that’s an easier thing to deal with because what you do is work to focus activities that are being done. You have people with the right idea; they just need to get a little more focused on execution of those ideas.
But what about when your team of inventors comes to realize that the necessary products/services are culturally ahead of the audience? That’s the trickier situation. Then the focus needs to shift to instituting the cultural change necessary. That last point is really important. Sometimes the one thing you will have to invent is the basis for a receptive culture.