Skip to main content

I Guess

 
I really enjoyed providing pre-production comments on Rich Rogers' book on quality, Changing Times,  so when the opportunity to do the same for George Dinwiddie came up recently, I took it.

Why? Oh, a handful of reasons, including:
  • I'm here for the testing and reviewing feels a lot like testing. (My definition of testing: the pursuit of relevant incongruity.)
  • There's the interesting intellectual challenge of finding a way to provide the kind of review being requested effectively and efficiently.
  • There's the interesting social challenge of delivering my thoughts in a way that conveys them respectfully, despite sometimes being critical.

George's book is called Software Estimation Without Guessing and I knew up front that there would be two rounds of review for it. The first was on a version with a couple of chapters still to be written, the second with all content present but further editing still required.

The publisher, The Pragmatic Bookshelf, provided clear guidelines on the kind of review they wanted and, in particular, they asked for grammar and typos to be excluded. Initially I felt that this might be a mistake — I could see them, why not point them out and reduce the chance they'd be missed later — but increasingly came to think that it was a good call. By ignoring them, I didn't break my flow to annotate stuff that is probably bread and butter to professional editors, instead delivering what value I could by commenting on the content based on my domain knowledge.

Pragmatic also provided a list of questions, which I decided to treat as an aid to reflection, and so this is how I approached the initial tranche of feedback:
  • I read from the beginning to the end without skipping forwards at all.
  • Along the way, I annotated the manuscript directly with suggestions, criticisms, and things I was wondering about. I hoped that understanding a reader's expectation at different points might be interesting to George in terms of structuring.
  • I didn't read in blocks of less than a chapter.
  • After each chapter, I re-read Pragmatic's questions and, in a separate text file, added fieldstones for each of them, and also for an "Other" category. These comments tended to be at a higher level than those made directly into the draft.
  • When I had read all of the material, I sorted and edited down my answers to the questions.
  • Finally, I reviewed my comments on the manuscript. To make it clear which comments were my first reactions and which had been made with the benefit of hindsight, I flagged this later round with "(2)".

Using Pragmatic's questions to structure my big-picture thoughts was useful even though talking to the editor later I found that they're a reasonably standard set. I treated them essentially as a checklist:
  • Who is the audience for this book? Is the book’s tone appropriate for that audience?
  • Is the book well-organized? Is the material presented in a reasonable order, and does it flow well from one topic to the next? Does the table of contents provide a useful guide?
  • Is the book correct? Are there any technical details that are in error, misleading, or perhaps recently superseded?
  • Is the book engaging? Do you want to keep reading it?
  • Is the book complete? Are there any missing topics, or extraneous topics that should not have been included?
  • Is the book consistent? Is the level of detail consistent and appropriate? How about the audience being addressed?
  • Would you recommend this book to others? Why or why not?

The second round manuscript provided the material that was absent in the first draft, but didn't change the other content. Again, I thought about how to approach it to compromise reasonably between the time I could put in, the coverage I was being asked to provide, and the depth I could go to. This is what I did:
  • I read through only the new chapters, annotating as I went.
  • Again, I read in chapter-length blocks.
  • I read through my answers to the publisher questions from last time.
  • Where it seemed appropriate, I provided new answers in which I was prepared to emphasise, downgrade, add, or remove my originals.
  • I reviewed my comments on the new material looking for inconsistencies between it and earlier comments.

Retrospecting on my methodology, I notice how natural I find this kind of cycle: dive in, record findings and feelings, reflect, choose a level of review and go again. I see it in my day job too. The publisher checklist gave me a structure in this case, but where I don't have one I'll usually distil it from the notes I've recorded.

The human element feels crucial to tasks like this. Beyond some Twitter chat, reading his blog, and watching a recent webinar I don't know George. However I've been on the receiving end of many reviews and know well my sense of indignation and self-righteous rightness when confronted with some thoughtful analysis that contradicts a line I've taken. (This is only amplified when changing my line would involve a lot of work.)

I try to bear this in mind when providing requested feedback, but it can sometimes be hard to balance humility and candour. When in doubt, for this task, I've tried to err on the side of my truth, hoping that'll be more useful to hear, even if it's dismissed.

And that prompts one final thought; although I doubt that he ever had any other intention, I found myself feeling the need to say this to George about my comments: "Ignore anything you want. It's your book!" That's not to belittle my effort, but to reflect the mindset with which I tried to approached the review. It's only my opinion and mentally tagging what I've said with "I guess" can help to remember that, as it's read but also as it's written.
Image: https://flic.kr/p/bTQwf4

Comments

Popular posts from this blog

Can Code, Can't Code, Is Useful

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "If testers can’t code, they’re of no use to us" My first reaction is to wonder what you expect from your testers. I am immediately interested in your working context and the way

Testing (AI) is Testing

Last November I gave a talk, Random Exploration of a Chatbot API , at the BCS Testing, Diversity, AI Conference .  It was a nice surprise afterwards to be offered a book from their catalogue and I chose Artificial Intelligence and Software Testing by Rex Black, James Davenport, Joanna Olszewska, Jeremias Rößler, Adam Leon Smith, and Jonathon Wright.  This week, on a couple of train journeys around East Anglia, I read it and made sketchnotes. As someone not deeply into this field, but who has been experimenting with AI as a testing tool at work, I found the landscape view provided by the book interesting, particularly the lists: of challenges in testing AI, of approaches to testing AI, and of quality aspects to consider when evaluating AI.  Despite the hype around the area right now there's much that any competent tester will be familiar with, and skills that translate directly. Where there's likely to be novelty is in the technology, and the technical domain, and the effect of

Testers are Gate-Crashers

  The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "Testers are the gatekeepers of quality" Instinctively I don't like the sound of that, but I wonder what you mean by it. Perhaps one or more of these? Testers set the quality sta

Am I Wrong?

I happened across Exploratory Testing: Why Is It Not Ideal for Agile Projects? by Vitaly Prus this week and I was triggered. But why? I took a few minutes to think that through. Partly, I guess, I feel directly challenged. I work on an agile project (by the definition in the article) and I would say that I use exclusively exploratory testing. Naturally, I like to think I'm doing a good job. Am I wrong? After calming down, and re-reading the article a couple of times, I don't think so. 😸 From the start, even the title makes me tense. The ideal solution is a perfect solution, the best solution. My context-driven instincts are reluctant to accept the premise, and I wonder what the author thinks is an ideal solution for an agile project, or any project. I notice also that I slid so easily from "an approach is not ideal" into "I am not doing a good job" and, in retrospect, that makes me smile. It doesn't do any harm to be reminded that your cognitive bias

Play to Play

I'm reading Rick Rubin's The Creative Act: A Way of Being . It's spiritual without being religious, simultaneously vague and specific, and unerring positive about the power and ubiquity of creativity.  We artists — and we are all artists he says — can boost our creativity by being open and welcoming to knowledge and experiences and layering them with past knowledge and experiences to create new knowledge and experiences.  If that sounds a little New Age to you, well it does to me too, yet also fits with how I think about how I work. This is in part due to that vagueness, in part due to the human tendency to pattern-match, and in part because it's true. I'm only about a quarter of the way through the book but already I am making connections to things that I think and that I have thought in the past. For example, in some ways it resembles essay-format Oblique Strategy cards and I wrote about the potential value of them to testers 12 years ago. This week I found the f

Meet Me Halfway?

  The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "Stop answering my questions with questions." Sure, I can do that. In return, please stop asking me questions so open to interpretation that any answer would be almost meaningless and certa

Test Now

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "When is the best time to test?" Twenty posts in , I hope you're not expecting an answer without nuance? You are? Well, I'll do my best. For me, the best time to test is when there

Rage Against the Machinery

  I often review and collaborate on unit tests at work. One of the patterns I see a lot is this: there are a handful of tests, each about a page long the tests share a lot of functionality, copy-pasted the test data is a complex object, created inside the test the test data varies little from test to test. In Kotlin-ish pseudocode, each unit test might look something like this: @Test fun `test input against response for endpoint` () { setupMocks() setupTestContext() ... val input = Object(a, OtherObject(b, c), AnotherObject(d)) ... val response = someHttpCall(endPoint, method, headers, createBodyFromInput(input) ) ... val expected = Object(w, OtherObject(x, y), AnotherObject (z)) val output = Object(process(response.getField()), otherProcess(response.getOtherField()), response.getLastField()) assertEquals(expected, output) } ... While these tests are generally functional, and I rarely have reason to doubt that they

A Qualified Answer

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn ,   Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "Whenever possible, you should hire testers with testing certifications"  Interesting. Which would you value more? (a) a candidate who was sent on loads of courses approved by some organisation you don't know and ru

README

    This week at work my team attended a Myers Briggs Type Indicator workshop. Beforehand we each completed a questionnaire which assigned us a personality type based on our position on five behavioural preference axes. For what it's worth, this time I was labelled INFJ-A and roughly at the mid-point on every axis.  I am sceptical about the value of such labels . In my less charitable moments, I imagine that the MBTI exercise gives us each a box and, later when work shows up, we try to force the work into the box regardless of any compatiblity in size and shape. On the other hand, I am not sceptical about the value of having conversations with those I work with about how we each like to work or, if you prefer it, what shape our boxes are, how much they flex, and how eager we are to chop problems up so that they fit into our boxes. Wondering how to stretch the workshop's conversational value into something ongoing I decided to write a README for me and