Unexpected Resumption of Proceedings

(Since this post is written in the first person, it’s worth noting up front that the author is Jesse Alford.)

This blog has been offline, at least on this address, for the better part of six months. I was going to transition to another stack*, because the way I wrote posts (Editorially) went away, and I didn’t enjoy any of the replacements. I let the domain mapping feature on wordpress.com expire. I transitioned to a better registrar. I exported the archive and learned how to transition it. I needed maybe four hours to figure it all out.

I don’t have four hours right now. I have a lightning talk in four hours, and will be in conference sessions until then. So.

I renewed my domain mapping and pointed my domain here. I figured out I can write in markdown and export to HTML with Mou, so I won’t have to compromise and compose in the wordpress interface, without even version control, like an animal.

I’ve been away from the online community for a couple of – wow, a couple of years now. I have been testing software, and developing software at Pivotal. I have been figuring things out, learning how much I didn’t know, becoming so embarrassed by my ignorance that I could no longer speak. I have been getting ready.

I’m at CAST 2015 right now, and I’m ready to start writing on this stuff a lot more. I’ve improved the quality of my ignorance enough to become articulate again. So I need this thing working, now, so I have a platform to articulate across.

I’ll see if the co-authors this blog originally described – or, indeed, new co-authors – want to join me in this, but for now, it’s just me, Jesse Alford. And, shock! I have things to say.

A prose version of this year’s CAST lightning talk (on the topic of testers pairing productively with programmers on feature-programming work) will be forthcoming, as well as a post around my longer-form session tomorrow.

Points Of Articulation

  • I am still going to make the transition to markdown/jekyll on Pivotal Web Services, probably. But I have a workaround for now, and now is when the site needs to be up.
  • It is really ironic how much more easily I articulated principles before having to grapple with practice. So clean, so pure! The principles can be articulated with experience, too, it’s just… harder. Abstract systems of belief are much easier to communicate with either no experience, or with enough experience. For a year, I had the wrong amount of experience. I think I might have just enough, now.

Focusing The Mind’s Eye: A Metaphor From Optics

(This text is adapted from an extemporaneous lightning talk I gave at CAST 2013. It attempts to follow the structure of the original, not the lamentable second performance. Naturally, it was this second performance which was captured on video; you can see it here.)

A Useful Metaphor

This is an article in two parts. This first part is about a metaphor I’ve found very useful: the tester as a photographer. This came up during the session on defocusing techniques Anna Royzman hosted at Test Retreat (which was great as a whole, by the way). Focusing and defocusing are terms I first encountered playing testing dice with James Bach, but it seems they’re fairly established, and I find them very useful.

So! Photographers. This is a class of people engaged in capturing specific information in a context that creates or emphasizes its meaning. For a professional photographer, adjusting focus is as much a part of taking a photo as pointing the camera and framing the shot is. As integral to the process as bringing the viewfinder up to the eye. It happens in the same moment; this is the level of skill and integration we need.

For a photographer, focusing is actually two problems, one of which is basically solved. The open problem is the matter of determining what focus is desired. This is a complex matter of skill, experience and aesthetics. The solved problem is how, mechanically, to implement the desired focus. This is a point of divergence for the testing metaphor; while photographers have devices of carefully marked rotating controls and precise lenses to implement their desired focus, testers focusing the mind’s eye are without any such complete, reliable solutions.

The Mechanics Of The Mind’s Eye

This second part focuses on the open problem I’ve just described: techniques for adjusting the focus of the mind’s eye. Our minds are not simple machines, and adjusting our focus can be very difficult to do, even assuming you know what you want to focus on (or stop focusing on). I am basically good at this, and I still have problems with it from time to time; for some, difficulty defocusing and refocusing is a dreadful problem.

I’d like to briefly share two of the techniques I use when I find I am having difficulty adjusting my focus. Things that help you focus can also help you defocus, which leads to a quick technique I learned from Star Trek: reverse the polarity. That is: wherever you find yourself drawn, whatever you are stuck looking at and thinking about and experimenting on, let it repulse you instead. Try specifically to blur it out. Whatever you were repulsed from, leaving blurry, try specifically to sharpen it.

Unfortunately (unlike in Star Trek), this quick trick does not always work.

The the more powerful focusing/defocusing/refocusing technique here is abstraction. When you are stuck seeing the world a certain way, with a certain focus, adding a layer of abstraction gives you controls you didn’t previously have. When you feel you’re out of options, metaphor gives you more (credit where credit’s due – this is something Jon Bach said when we were discussing the original lightning talk). One concrete technique I use to use abstraction on the focusing problem is to draw a card from The Oblique Strategies. I've got a deck of my own that I've made, but there's also a very handy online version. Here are a few examples:

Intentions -nobility of -humility of -credibility of
work at a different speed
The Inconsistency Principle
Don’t break the silence

Some of these may directly solve your problem by shifting your mind to a new (useful) point of focus. But it’s almost better if they don’t; for instance, how does that last one directly inform testing? Your mind will have to create a metaphor in order to use “Don’t break the silence” to inform your testing, and the creation of that metaphor will give you the tools exert more control over your focus.

If you’re stuck or trapped or having difficulty refocusing your mind’s eye, the most powerful tool I can offer you is metaphor, however you choose to invoke it. Creating or understanding a metaphor requires your mind to systematically abstract things that might previously have only occured to you as concrete; in that moment of abstraction, you are free.

(Since I had ten seconds left at the end of my talk, I found it a useful time to note that it is in fact possible to hire me to do testing on your product. It seems prudent to repeat that note here.)

Points Of Articulation

  • Consider also: auto-focus. (Jon Bach asked about this after the initial lightning talk; I consider auto-focus to be highly analagous to noticing. There’s a lot of nuance to be explored there, though.)
  • The optics metaphor extends beyond photography; the lenses used in rifle scopes, astronomy, microscopy, lasers, etc. can all be useful analogs.
  • One issue with this metaphor is in its complexity; when we talk about focus, are we really talking about zoom? If not, what is the relationship between zoom and focus in testing? Exploring such questions can make the metaphor either more interesting and useful or confusing and meaningless.
  • “The Mind’s Eye” is homonymous with “The Mind’s I” which is less about vision than identity. Perspective and context are also largely about identity, so this is interesting and appropriate. Doug Hofstadter edited a compilation that takes this homonym as its title. I recommend it.
  • “The Mechanics Of The Mind’s Eye” has some awesome ambiguity; perhaps (in addition to the intended meaning) this could be a term for people teaching testing skills? Observation skills generally?
  • This whole metaphor is applicable to many things besides testing, being useful to basically anything I would describe as art; someday this point will link to a post discussing the definition of art and its relationship to testing.
  • Really, abstraction, metaphor and model-building drive the Star Trek technique, too, if you think about it.
  • I owe a debt to the old computer game Marathon for the closing wording here.

Minimum Viable Blog

The Part About Inaction And Counters To It

I love the phrase minimum viable. I love it for various reasons, but the simplest of these is that it helps me counter my particular experience of perfectionism.

Perfectionism is the enemy of most productive behavior. Some suffer from it worse than others. I have a particularly nasty strain of it: in the event that I believe I will not be able to do a near-perfect job, my first instinct is to not do the job at all. Since perfect work is mythological, and I know it is, a minor effort of thought is sometimes all it takes to decide not to do something I have cleverly convinced myself is impossible. Inaction is unbecoming and even tragic; it is widely held that inaction was Hamlet’s tragic flaw, for instance.

This is unacceptable. Things need to get done. Not only that, but I am fairly convinced that I personally have to do some of them. This is where minimum viable is such a help. It doesn’t have to be perfect (whatever “it” is) to be worth it. It just has to be barely good enough to serve whatever end it’s working toward. Now, it often ends up a lot better than “barely good enough,” but this criteria is a lot more practical than “as near to perfect as possible.”

This latter criteria is often default, unvoiced, unexamined. It may find its form as “the best I can do” or something similar; clinging to it is a good way to join Hamlet in his tragic flaw. He might’ve benefited from considering a minimum viable regicide plan and working from there; we could’ve been spared that whole play-within-a-play business. He clearly understood the problem when he said,

And thus the Native hue of Resolution
Is sicklied o'er, with the pale cast of Thought,
And enterprises of great pitch and moment,
With this regard their Currents turn awry,
And lose the name of Action…

When inaction is unacceptable (and/or likely to lead to unnecessary tragedy), minimum viable helps me keep “the name of Action.” I prefer to be a hero of the non-tragic variety whenever possible.

A related term I sometimes find useful is satisfice. My preferred definition holds that satisfice is “optimization that takes the cost of optimizing into account.” The fact that I prefer this definition reveals once again my latent perfectionism; a better definition might be “the art of the good enough.

Minimum viable is an idea I use in support of actually satisficing instead of pretend-optimizing and then actually not doing anything. Satisfice is a process, and creating the minimum viable x can be an early step in that process.

Creating something with the intention of making a minimal first step also leads naturally to feedback and iteration, which are also often useful for satisfice; early “optimization” without feedback or with a very long feedback cycle is even more naïve than “optimization” that doesn’t account for its own cost.

So, I love the phrase minimum viable, owe Eric Ries a debt of gratitude for popularizing the term to the point that I encountered it, and this is my minimum viable blog launch.

The Part About Launching This Blog

My criteria for a minimum viable blog were simple:

  1. I should have sufficient control over it that effort invested into it is unlikely to be lost and change is easy.
  2. It should have visual characteristics that make it easy to read.
  3. It should be valuable to some person other than me.
  4. It should be something I can have running smoothly within a day or two of starting.

To satisfy these conditions, I opted to:

  • register a domain name of my own (so that I can easily re-point it if my implementation needs to change)
  • use wordpress.com, at least at first (fast, easy to make readable, easy to export from).
  • use the the Blaskan theme, which I found by googling “wordpress.com theme readability” and settled on very quickly.
  • compose posts in Editorially to allow me to compose quickly and comfortably in Markdown, collaborate easily with my co-author and reviewers, and produce additional remote and local copies of my work as a welcome side-effect of moving posts to WordPress.
  • recruit my sister as co-author, which makes it more likely that the project will have ongoing value.
  • use as launch material my lightning talk from CAST 2013 (it was very well received and I promised people I’d blog about it, so I know there’s some other person who this is valuable for, and since the logical framework and some of the language were already known to me, it was fast to write).
  • explicitly choose a format with an note-dump at the end so all the ideas that crowd me as I’m trying to write can find minimum-viable-expression and leave me free to focus on what I mean to write.

As it stands now, here’s roughly the procedure I use to post content here:

  1. Create a document in Editorially and write a post there, sharing it with my co-author and working on it on and off over the course of a day or two, dumping ideas that don’t fit into the flow of the post to Points Of Articulation at the end.
  2. Export that document to HTML (and file the .html doc the export process creates in a backup folder), briefly review the markup in Notepad++, and copy/paste it into the Text view of the WordPress.com editor.
  3. Preview it, notice any glaring errors (especially in markdown-to-html-translation), correct in editorially if necessary (and re-export, re-preview).
  4. Publish it, then announce it by tweeting the link.

This is probably not, strictly speaking, the minimum viable blog-post procedure, but I have lost enough work to the whimsy of WYSIWYG editors in the past that it was the lightest procedure I felt comfortable with.

Points Of Articulation

  • There will be a seperate post, soon, to explain more thoroughly what this Points Of Articulation section is for (probably in combination with an exploration of the name of the blog itself); for now, expect to see one in every post.
  • Yes, I appreciate the irony of an elaborate Shakespeare reference in a post about executing a minimum viable blog launch. This illustrates again that action motivated or enabled by the idea of minimum viable are not always necessarily executed in full accordance with it, and that’s fine.
  • Editorially is in closed beta. If you’d like an invite, are interested in blogging, and have met me, (the internet can count, here) ask.
  • Jerry Weinberg wrote a book called Perfect Software: And Other Illusions about Testing. I haven’t read it. I expect that it bears on the issues of perfection and satisfice, though, and this will be a good place for a link to the eventual review, when I get to it.
  • I’ve pointed it out elsewhere but it bears repeating: the awesome idea for the name of this blog came originally from Aubrey, and I am very glad we have it.
  • If you are interested in examining Hamlet’s tragic flaw from a variety of (hilarious) angles, I recommend To Be Or Not To Be by Ryan North. It’s a choosable-path-adventure-story parody of Hamlet. Shakespeare’s path through the story is marked; after a couple of instances of seeing The Bard choose things like “have a nap” over “go kill Claudius,” I developed a special appreciation for the raw scale of Hamlet’s tragic inaction.
  • Satisfice is the name of James Bach’s site. His blog was my introduction to the term.