inability.org

Lately I’ve been doing a little thinking about how the different “brands” of history contain more than a little helpful guidance for software testers.  While I can already feel the eyebrows of my professors fixing themselves into skeptical formations, I still feel it’s a valuable exercise to try and work out what I might exactly mean by that here.  Recent discussion on how the history of science, with its obvious parallels to technology and the history of ideas, forced me in a way to take a hard look at what all those history classes actually did for my software testing skills.  During StarEast I scribbled quite a few notes, bubbles, and angry robots pointing at diagrams with more bubbles referring to how social history, political history, military history, intellectual history, gender, historicism, post-modernism and other theoretical approaches have shaped my thinking about how software comes into existance, who uses it and how, and what this means to the tester.  After all, software is an almost ephemeral embodiment of ideas, born of conceptual discussions in meeting rooms and already frustrated workflows looking for new meaning.  In my world the software sits at a busy intersection of the maintainance of human physical existance (by that I mean medicine), the social, political, and professional world of clinicians and hospital administration, and the steady flow of physics and computer engineering.  Any one of these traffic conduits can be disruptive to the other and by nature, I usually start with the social.

Social history is one of the methodologies of history that became in vogue in the 1960s (though even that could be argued).  There are more than a few approaches, including the Annales school, quantitative analysis and the idea of studying history from the margins or “from below” (working class, etc).  All of approaches have merit in some way when applied, however disjointedly, to software testing.  At some point I have ambitions to go into further detail on each type, but for now I will just take social at face value and stop short of sociological.  In the software world we discuss our users often as we would discuss our children.  We must not frustrate them unduly, and protect them from the harm of nasty bugs who want to make them cry as well as the things that hurt them without them even knowing.  But how can we do that exactly?  Software testers can take a variety of measures to keep themselves objective (hello jack-in-the-box, stay there for just a minute in your box, SVP), or work on a variety of cognitive skills.  We can talk to experts.  What social history has done for me is to remind me of  the margins.  One of our simplest products at work, the one which sees the least code changes, is one I often see users complain about.  Early on in my training I met one of these users.  She had lots of pictures of cats, she worked with all women, 10 of them, in a windowless room together.  They were the least trained and often the last people in the workflow (that last part gave me a “sister, I know” feeling) and they did very similar work all day.  They have a pattern they recognize and they apply it repeatedly in a factorylike way all day.  So what happens when the software breaks?  It destroys their world.  They rarely dealt with exceptions, but when they happened, they were always misreported because they had no exposure to anything but their own pattern.  So, as a tester, I have to remember this room and these patterns that bring these women a strange comfort.  When new features or system design comes about, how many ways will it disrupt this pattern?  Does the pattern lie?  Can I manipulate things in the background to give a smooth green-light appearance that just masks the chaos below?  Just like in social history, this group of users are often not the decision makers in their own professional lives.  Much of the system, and other users, do this for them.  By knowing this, by caring to know about the social environment in which these people work, I can be a better tester.

Low-hanging fruit post #1.

After awhile, email and written scribbles become insufficient media for capturing ones thoughts.  Thus, thoughts.  Plus my writing has become this impossibly rushed and overly self-monitored activity, an aspect of cramming too much into daily life.  So I will practice and capture here.  The domain has been a landing spot for many projects in the past, from amateur wrestling to art-science shows full of steaming chemicals and painters in lab coats.

So my thesis thought work has a place to live.  Hopefully it can co-exist nicely with my rambles on software testing.  Together they can entertain whatever comes to mind, though a house rule may be to exclude the hopelessly mundane.  Special projects, urban golf comes to mind, might also end up here.  I probably should also get started on cucumber sandwiches and find a really ridiculous pair of shorts…