I have been churning on the idea of ‘tests as conversations’ for the last week or so. One part of this involved the skills necessary for the conversation to happen. Specifically whether knowing math and concluded that no, you do not needed to know math. Except when you do.

Huh? That’s pretty have-it-both-ways even for me.

Math is a ridiculously large field of study, so it is near impossible to say that you do not need any math, but the slice of math I think testers need to know is pretty slim.

• Basic statistics (mean, median, mode, standard deviation, sample size, etc.)
• Combinations
• Permutations

Yup. 3 things, though I’ll concede that the first one is a decent sized bucket. In over 10 years of testing I have not had to employ any math outside of those areas. Even when testing a banking application I did not have to flex my math brain as the bankers created oracles for us to verify against.

Of course, this is heavily dependent on my own experiences. I have never tested an application that is heavy in its math, like a missile guidance system for instance. I would likely argue that at that point what you want is not someone who is conversant in math, but someone who is deeply fluent in it.

I have been out of high school 12 (or 13 years; I can’t remember) which was the last time I had to do any serious math. I can still do long division, but I had to teach it to my daughter when she was in public school. Calculating the square root of something? Not a chance.

And that is ok. In no way does this lack of knowledge impact my ability to have the conversations I need to.

I’m often accused of / introduced as being a pessimist. I was recently listening to a JaysTalk when J.P. Ricciardi (The Blue Jays GM) gave the quote A pessimist is an optimist with experience.

I think the key part of that is experience. Pessimism is often considered a negative trait, though I think it also has its uses. Especially where risk management is involved. And testing is essentially a risk management exercise. So I would contend that being a pessimist is learned, and valuable, if not essential skill.

While trying to find the source of J.P.’s quote, I found this one over at Urban Dictionary

• An OPTIMIST is a person who doesn’t have all the facts.
• A PESSIMIST is an optimist who does have all the facts.
• A CYNIC is a pessimist who has seen the facts in action.
• A PARANOID is a cynic who has FINALLY realized that the facts are after him.

Perhaps then this is really some sort of scale or curve and you want to be at the Cynic point. After all, at that point history would tend to back you up on your points. Take for instance the classic justification for not fixing something; ‘No one is going to do that’. The pessimist would respond with ‘but they might’ or something similar. The cynic could respond with ‘the last time you said that, they did, and we had to rush a patch out which botched the schedule by 3 weeks’.

Writing Excuses has talked a bit recently on Editors and the editing process. One misconception is that editors identify the spelling / grammatical / accuracy errors. That is actually the job of the copy editor. Editors take something good and try to make it great. In this week’s they are talking about the process where an editor works with an author on revising a book.

• Some authors are gracious of feedback from editors
• Some authors protect their work pathologically
• There is a difference working with new(er) authors than ones who have been doing this a while
• Editors are not omniscient and so might miss things the first time (or two) through
• Editors are looking for consistency with self and the larger world the book inhabits (internally and externally)
• Editors see things that the author did not. Why? Because they have been doing this for a long time
• Responses from the editor often elicit ‘Oh! I should have thought of this!’ responses from the author
• Responses become the catalyst for a conversation
• Editors are not trying to fix, but make it better
• Ultimately it is the author’s book. The author can overrule a change. Editors try to show why it is not right, and possible solutions
• Editors are not writers. They may know how to write, but that is not their job. (A doctor can fix your heart, but they can’t pump your blood for you)
• At least half the success of the editorial process is dependent on conversation
• Writing and reading are two very different skill sets
• Authors need the input of editors because the writer is too close to the content
• While you can cut out editors from the process and self-publish, that is not a step you necessarily want / should cut out
• Printing is the least bit part of publishing
• Sturgeons Law – 90% of everything is crap

Now, substitute ‘developer’ for ‘author’ and ‘tester’ for ‘editor’. See how it still all makes sense?

With Remy back in school and Kathy working mornings my morning commute is now 2.5 hours some days so hopefully I’ll catch up with the podcasts.

The first one is Schuyler Erle speaking at Where 2.0 about his experiences with the Mumbai Free Map. His main point is that ‘maps tell stories’ though he seemed to have lost the plot on that a bit. The last 10 minutes however are really informative by providing some gotchas that they Open Street Map project has experienced.

• the notion of ‘a community of interested individuals’
• some implied features of any collaborative project
  • change feeds
  • change histories
  • change diffs
  • rollbacking
  • provenience – not only who a change contributor is but they had the right to do so
• create a ‘way of keeping score’ – turn participation into a game to leverage natural competitiveness
• understand that specialized knowledge domains exist (pokemon, chemistry)
• things to watch for in a tagging system (or in this specific case a key/value system)
  • same class of thing expressed with different key
  • same key, but different values
  • what does ‘approximate = yes’ mean?
  • opinion should not a descriptive data (‘wrong = oh yes’)
  • same concept / name in different languages (for example, cities in Wales)
  • basic human error – when there are multiple spellings for something, which is correct? Need that specialized domain knowledge…
  • how do you express units? globally or locally?
• tag equivalence classes has great potential for unifying community tag folksonomies

There are a number of things listed there that to me provides another example of why leveraging 3rd party libraries makes sense for these sorts of things. Sure, providing a field for tags is easy. As is just displaying them on a page in a ‘tag cloud’-ish manner. But getting all the other stuff right? Not so easy.

And it only gets hard when you change domains to crypto.

File this under ironic as I tend to overfill my plate with responsibilities, but I found another article in my bag regarding something I need to actually start executing on. Actually, it is part of a much larger theme of saved stuff.

The first article is the one from the bag and is Learning to say no at work. Here are the copy-and-pastes of interest.

• You may take on too much and get burnt out or end up taking on the work of others. Either way, the perception that others have of your performance will suffer
• If you say “yes” to too many things, you’ll spread yourself too thin and won’t perform well on anything
• Saying “no” in some cases can actually gain you more respect

The next article was from the Quardev Quarterly newsletter by Mike Kelly in which he talks about saying ‘no’ as a consultant:

Another hallmark of a consultant you can trust is one who turns down work or leaves money on the table. I turn down work for two reasons: availability and lack of experience in what I’m being asked to do. If I am taking a stretch assignment, I let the client know up front. If I finish something early, I deliver it early – even if I have approval to bill for more hours under the current contract. The consulting companies I’ve worked with who do the same are the companies I recommend to my clients when I have no availability. Turning down business that’s not right for you is an important way to build trust because the client can see that you will choose doing the right thing over closing more business.

The common thread between the two is that saying no builds respect and trust, produces better results and improves the quality of your work by not overstretching yourself.

Stephen Friedman wrote an article in the February 27, 2008 National Post (I’m cleaning my bag and finding some old clippings) called A good team player needs to be selfish. This seems to fly in the face of the standard ‘there is no i in team’ convention. Here is the final paragraph:

At the heart of this issue is this: Selfishness has become an insult, a dirty word, in organizational life. But it is only really bad when the goals are solely power, control, greed or harming others. When we make righteous choices, odds are they are the right ones, even if they may look selfish to others. Teamwork is a great idea, but it should not be the be all and end all of organizational life and productivity. Just like using the oxygen mask in an airplane, sometimes you have to take care of yourself to be able to take care of others.

Job satisfaction and work-life balance are cited as places where it is okay to be selfish. Perceptions of selfishness are also present when acting as the bringer of change as QA people are often there to do. The message here is that it is okay to be perceived as such as long as your motives are not individual in nature.

I received Steve Loughran and Erik Hatcher’s Ant In Action to review well over a year ago and I actually thought I had posted a review for it before now. Digging through my site though it appears not. Which sucks, because this is a great book.

When I was reading Ant In Action originally I was working in a Java shop as the QA / Tester. (I have also been the build person at various times for different organizations.) One of the first things I tend to do on a project is extend the build system to include static checks to try and catch the low hanging fruit. On this particular project it meant wading into the quagmire that was their build system. Without a word of exaggeration, one task required ant to call perl which shelled out to call ant. After reading this book I could have easily wrestled the build into submission.

The structure of the book was well thought-out, which is not surprising as this is the renamed second edition of ‘Java Development with Ant’, with a consistent example that starts out with compiling a single class and ends up dealing with a number of the pains one experiences with large-scale enterprise projects. There are any number of pages on how to use Ant in its most basic guises, but it is these more advanced topics where the book shines.

• Working with big projects – Build chaining is hard, and likely always will be. It does not however have to be messy and chaotic
• Managing dependencies – A nice introduction to the Ivy dependency management system. I’m quite convinced that if you are not migrating from Ant to Maven you should be incorporating something like Ivy into your build system. This chapter explains to start managing your dependencies and even includes a section on publishing to a local repository which is important in a corporate context.
• Working with XML – The build system I was working with had a large number of servers that could be deployed to. Each had its own set of XML files which differed by only a line or two. The Working with XML chapter would have cleaned this up a lot.

Those are of course in addition to the earlier chapters where you learn about datatypes, parameters, packaging, deployment and other day-to-day items. Also, it is definitely worth mentioning that the first topic really explored in depth is integration of JUnit into your build (Chapter 4) which absolutely appeals to the tester part of me.

Because I can’t just be happy with a well-written book that taught me a lot, here is what I would change for the 3rd edition if they produce one.

• Include blank pages at the back of the book for note taking
• While it is great the integration of static analysis tool Checkstyle is shown, including FingBugs or PMD would have rounded out the section by including dynamic analysis as well
• Use the CruiseControl as the server in Continuous Integration chapter. They explain why they did not, but that is the server most people reading this will be using.

Overall, this is a fantastic book that should be on the shelves of any Java shop still using Ant and should be mandatory reading for anyone whose job involves modifying Ant’s build files.

Now all I need is Ant In Action-esque book for Rake.