Thu, 19 Apr 2007
Tumultuous change hereabouts. After a mere 23 years, I've stopped using emacs for writing code (having switched from it to TextMate for Ruby). And after a mere four years, I've switched my blogging tool from blosxom to Wordpress. Yes, there are comments. They may even work.
You may thank Kevin Lawrence for finally shaming me into making the weblog switch, and American Airlines for getting my wife to London twelve hours late (so far), which gave me the time to write an incredibly long first entry (my SPA 2007 keynote).
The new blog's address is http://www.exampler.com/blog. Things like the blogroll and look'n'feel customization won't happen soon (since it appears my wife is on the plane and the plane is in the air).
This is the another step in my multi-decade switch from testing.com to exampler.com. "Exampling", though not a verb, is a better description of what I do now. It includes testing, but has a larger scope.
Tue, 27 Mar 2007
I'm in England, jetlagged. Some person from the States just called my cell phone / alarm clock with a wrong number at 3:00 a.m. local time, and I can't get back to sleep. I am therefore going to do something I will regret in the clear light of morning.
The Agile Alliance recently published its position on certification. I wrote it. I was told last evening, and I believe it, that people have been interpreting it to have the message "you better get certified if you want a job in Agile." I have long maintained, as a matter of both principle and practice, that a misunderstood message is the fault of its sender. But Jeez Louise, the letter is pretty explicit:
The last few years have smacked me in the face with that kind of thing over and over. People are so apt to jump to conclusions, to assume that any unknown motive must be a bad one, to focus on pointing out weakness to the exclusion of helping shore up strengths. Trying to accomplish something positive is just too damn much frustration not to get paid for it. I say it's spinach, and I say to hell with it.
Mon, 19 Mar 2007
The Pacific Northwest Software Quality Conference is one of my favorite conferences. I think it usually runs about 200 people, so it's small enough to meet people. As a regional conference always in the same place (Portland, OR, USA), there's a continuity of attendees that allows some papers to be less introductory than in other conferences.
They tell me:
Sun, 11 Mar 2007
I need a picture of Jeremy Stell-Smith to use as decoration for my SPA 2007 talk. (It's background for a story about an epiphany I had while pair programming with him.) I no longer have his email address. If you do, could you forward this request to him? Thanks.
This all seems to have some connection with tests-as-examples. It is probably useful for an example to be memorable. We want it to come to someone's mind at the moment it's relevant, not be something that has to be looked up.
That implication may clash with my usual advice to strip a test down so that each word that appears in it is essential to its purpose. (So, for example, the only tests that would mention a user's username and password would be tests about logging in.) It is the added detail in the stories above that make them memorable.
It may also clash with my advice to keep tests simple, at least at first. Complex, even humorous, soap opera tests (reg. required) like the following are more memorable partly because of the complexity.
It does support my habit of using real people (or personas of same) as test data. The above was partly inspired by my perennial inability to remember the make, model, or color of my rental car when I walk out of the hotel in the morning. My various veterinary clinic examples feature clinicians based either on real people or stereotypes (the impatient, judgmental surgeon).
(I should note the danger of using real people - by focusing always on a limited subset of the potential users, you become even more likely to overlook examples relevant to people outside that subset.)
In any case, I bring up Schneier's quote because this kind of thing will be important if tests ever take their place as a communication and discover tool, in addition to a bug-finding tool.
Fri, 23 Feb 2007
I'll be in London at the end of March. While I'm there, I'd like to have a little workshop for Scrum product owners, XP Customers, and product directors. These are the people who:
I believe those people have the hardest job on Agile projects. They are also the most likely to be isolated: programmers talk with programmers, testers talk with testers, but these people often have no peers to talk to.In this workshop, I want to gather up to 20 of these people and have them teach each other about problems they've solved. We'll use a particular format (described below) that's proven effective for such things.
The dates will be on the 29th and 30th of March (total time one and a half days). There'll be some fee to cover expenses (not exceeding £50). We'll select people on the basis of one-page statements of the problem they had and solved.
People who are programmers, testers, and project managers can also come, but product directors will have precedence.
I'm sending this note to gauge interest and decide whether to book the room (at the Royal Statistical Society, 12 Errol Street, close to the Barbican centre). Please forward it on to likely candidates.
I'll decide on March 2, based on how many product director types send me mail saying they're interested.
Questions to me: firstname.lastname@example.org.==========
Depending on interest, we may also have lightning talks or breakout sessions.
This format is a variant of the one used in the Los Altos Workshop on Software Testing.
Thu, 22 Feb 2007
Fit has some problems:
Maybe I'm groping toward a solution.
Here is a Fit table that talks about a data conversion that's driven by a configuration file:
That looks reasonably attractive. You'd be appalled if you knew how much time I spent on it.
Here is the same test in a different format:
That's an OmniGraffle file. I think it required less fiddling to create. Updating seems to be easier. I think it would be more useful as documentation than the previous test would.
What I've done behind the scenes is extend my existing Graffle parser to handle files like this. I still use the Fit engine behind the scenes, as you can see from the output:
Not so nice to read, but how many product directors really look at test output?
Now the question is: how could this use JUnit as the test execution engine instead of Fit?
Then the question after that is whether I could use a less obscure app than OmniGraffle to generate the tests. Anything that puts out XML should be roughly the same difficulty.
Tue, 20 Feb 2007
Here are three sites that use pictures to show what Agile artifacts and physical environments look like.
Sun, 18 Feb 2007
Two interviews with me recently went online. The first, at On Ruby, is about Ruby, amazingly enough. Also about Everyday Scripting with Ruby. The second is from Dr. Dobb's and is mainly about testing in Agile projects. A lot of overlap with this blog.
While I'm talking about metaphors...
A very long time ago, I learned to fence. What you see above is a lunge. A lunge moves you from a defensive posture to an attacking one—you're trying to stab the other person. But notice that the figure is balanced. Its center of gravity is between its feet, and it could remain in that position without tipping either forward or back.
If its opponent counters the attack and launches a counterattack, it could recover backward by pushing off the front leg, snapping the back arm up, and reassuming the original en garde position:
But suppose the opponent retreats away from the attack. Then our lunging figure can recover forward: keeping the center of gravity as is, pull the back leg in and curl the back arm. Now it's ready to keep pressing the attack: it can lunge again or move forward in a more guarded way.
The important thing here is that—despite the failure of the original attack—the manner in which it moved forward allows it to keep moving forward.
Software teams often seem to be unable to recover forward. If they make a wrong decision, they land off balance:
scramble awkwardly backward (
Or they can bull forward along a path they would not have chosen, had they known then what they know now, jabbing repeatedly and getting more and more off balance:
What they're unable to do is make use of where they are to take what now appears to be the best path:
For those of us who are merely mortal, it seems the best way to be able to recover forward is to practice the right stance. Get yourself into lots of situations where you end up going down the wrong path. Instead of reverting backward to a known stable state of code, add and rearrange code to move forward.
A good way to get yourself into those situations is by only writing the code that's needed for the small feature you're working on right now. Then some later small feature will make you recover forward—and learn about how your stance is imbalanced.
Some people believe you can recover forward from pretty much anything. (Ron Jeffries' Extreme Programming Adventures in C# demonstrates recovering forward from a design that doesn't support undo to one that does.) Others don't. I don't know what my opinion is, but I believe most people could recover forward a lot more than they think they can, if they practice.
The trick is persuading them to practice.
Credits: I learned to move forward instead of revert from Zhon Johansen. The first photo is from Dr. Stephan Dann and is licensed under the Creative Commons Attribution-ShareAlike 2.0 license. The second photo is from http://www.tcnj.edu/~fencing/glossary.htm; there's no copyright notice, but it looks to be from an old fencing book.