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 just realized I had a couple issues of trade rags sitting around. Here are the things that caught my eye in the Software Test & Performance ones. Aside from the really bad author photos that seem to be used and that I could write some of these articles (and I don’t work for a tool vendor or am selling consulting services).

STP – June 2008

• Slipping Into Scrum by Rob Sabourin
• Covered in Java by Mirko Raner is a nice introduction to coverage (by a parasoft employee)

STP – July 2008

• Coverity’s thread analyzer tool
• 5 Fatal Flaws of Estimating Tests (by L.R.V Ramana)
  • Asking the Wrong Questions
  • Arranging Activities Illogically
  • Failure to Understand the Multiplier Effect
  • Inconsistencies in Measurement Criteria
  • Not Compensating for Risks and Dependencies

STP – August 2008

• Talend Open Profiler looks seriously cool. Too bad I’m currently in Rails-land and can’t really use this as well as I might be able to do if it wasn’t for ActiveRecord.
• There is a decent article on Maven and its role in testing, but I would point you here, here, here, and here instead.
• Jason Cohen is promoting his book with an article called ‘Think You Have A Team? You Don’t.’ I haven’t read the book yet (it is in the pile) but the article is pretty good. Including choice tidbits like Peer code review not only finds bugs, it creates an environment where developers work together instead of in parallel.

STP – September 2008

This issue is Windows focused which is something I haven’t really be involved in for 3 years, so it should be no surprise if there is not a lot I find interesting. If you are a .NET shop, your milage will be much better.

• tagline from a Gomez ad: Just because your infrastructure survived the load test doesn’t mean the customer experience did
• The ‘Construct A Data Framework For Seamless Testing’ by Vladimir Belorusets is pretty good for the Toolsmiths out there, or anyone else building their own custom framework.

I play recreational Lacrosse which is not that unique an event where I live. What is somewhat unique is that I did not play as a child. Growing up I played baseball from t-ball all the way until I was 16. This means that I do not have the thousands of hours of muscle memory and skill as other players on my team.

One such player this fall is the captain of the Brooklin Redmen; the local Major Series team. He is good. Scary good actually.

I mentioned this to a coworker, he pointed out that sport holds all sorts of these gaps in skills:

• Never done it before
• Purely recreational
• Competitive recreational
• Semi-professional
• Professional

Between each of these categories is a significant jump in the skill of the participants and the level of work needed to achieve the next level. In lacrosse I would fall into the ‘Purely recreational’ category. In order to play in the ‘Competitive recreational’ level I would have to start eating (far) healthier, start a running regime designed for both bursts and longer time period stamina and spend a lot more time with a stick in my hand.

I’ve now been doing QA / Testing for 10 years now and consider myself in the ‘Professional’ category. What strategies do I think worked in my favor in making the jump between levels?

• start writing – writing requires thought and thinking is a key skill of testing
• join a community – being part of a broader community gives you a venue to experiment with thoughts and provides a sounding board for questions
• start teaching – there is a big difference between ‘knowing’ a concept and having internalized it enough to be able to communicate it effectively to someone who does not have it figured out yet
• bite off way too much – I learned unix by formatting my windows partition which meant that if I wanted a working computer I needed to get it working (took a bit, but I did). I’ve done the same thing in testing over, and over from my first day at my first job (‘Sure, I can write you a database that can do that…’).

As always, where are you in the progression, and are you willing to do what is necessary to move up. If of course you want to that is.

The Danish philosopher Soren Kierkegaard was quoted on the newest Hugh and the Rabbi and I immediately thought of the unceasing battle against ‘best practices’. Here is the Kierkegaard quote:

Life can only be understood backwards, but it must be lived forward.

While the quote itself is good, the commentary surrounding it (I think from Johnnie Moore, I don’t know their voices) frames the problem even better:

… so many efforts where we see what happened in the past, turn it into a model and project it merrily into the future and don’t pay any attention to the fact that things change, people change, people are different, every context is different.

Seems like a pretty good framing of why Best Practices are myths.

JR has a recent posting about assistants which got me thinking about the concept. In a software shop, I have seen three different ‘types’ of assistant.

1. The office mom/dad – Makes sure the developers have coffee, birthdays are recognized etc. Very important with start-ups where there is not a lot of structure / policies which force the organization to flow on its own inertia and there is a lot of work keeping people (too) busy
2. The classic assistant – Makes appointments / juggles the lives of the people they are assisting. Our CEO and one of our Directors share one and she is constantly herding them from one speaking engagement to a sales call to a whatever
3. The unofficial assistant – This one is a bit of a stretch, but much like we are all customers we are also all assistants. For instance, even though there is a direct reporting line between myself and my boss (Hi Mike) I take a number of tasks on that don’t technically fall under my job description (well, they might as I have a pretty vague one) to assist him with his queue. Similarly he will take some things from my queue since he is better connected politically within the organization. Another example would be when I change our product’s administration layout for another department. I don’t work for that department, but I’ll assist them where I can.

If you have ever witnessed an effective type 1 or 2 assistant in action you can appreciate their value. I would argue that the third is exponentially of more import though. The trick is to identify who you assist and who assists you so those relationships can be leveraged to your and their benefit.

Different companies react differently (which makes sense) to Bug In The Wild reports. Too often you hear about reports in a security context where companies have responded with a pack of lawyers. EA however has recently illustrated how to capitalize brilliantly to a BITW.



I originally found this on Neat-o-rama where someone in the comments suggested that the original report might have been faked to setup the response, and I can certainly see that happening. But it is too good a concept to let that overshadow it.