Skip to main content

Book Notes

I've had a good run of reading in the first three months this year and I thought I'd try to summarise it  by picking out one or two thoughts on each book.


Becoming a Technical Leader, Gerald M. Weinberg 

I'm not a vain or pretentious kind of chap, but I did enjoy discovering that leadership is all about moi. That is Motivation, Organisation and Ideas.  A good technical leader will look to supply these things in the right measures at the right times for their teams; a great technical leader will look at themselves to see which of these is their weakest and find ways to work at improving it.


What Did You Say? The Art of Giving and Receiving Feedback, Charles N. Seashore, Edith W. Seashore, Gerald M. Weinberg

Before I started regular 1-1s with my test team last year, I cast around for ideas and found a series of Manager Tools podcasts which, despite being much longer than it needed to be, I liked a great deal. A few months in, I was looking for ways grow my own capacity in delivering feedback. One quote from What Did You Say? hits the spot:
Don’t concentrate on giving feedback; concentrate on being congruent–responding to the other person, to yourself, and to the here-and-now situation. Don’t go around hunting for opportunities to give feedback, because feedback is effective only when the need arises naturally out of congruent interactions.
And just last week I came across No Magic Words  which aligns really well with the notion (and I hope practice) of 1-1 that I have arrived at.


Are Your Lights On? Donald C. Gause, Gerald M. Weinberg

Weinberg has a knack for pithy yet panoptic definitions. You're undoubtedly familiar with the widely-quoted definition of quality and in this book he provides another:
A problem is a difference between things as desired and thing as perceived.
Both desire and perception are up for grabs in any resolution of the problem.

You'll often see an iceberg metaphor being employed to illustrate limited visibility of some bounded-but-extent-unknown larger issue. Reading Weinberg for me is like taking that iceberg and picking off a snowflake from the top. It's easy to behold, even easy to hold, easy to comprehend at the high level but as you begin to think about it, deeper and denser than you imagined. In fact, as you look more closely you realise that that snowflake is itself an iceberg and, actually, it's icebergs all the way down.

The Gift of Time, Fiona Charles (ed.)

This collection of essays is a tribute to (and 75th birthday present for) Weinberg and is strongly influenced by his teachings. Michael Bolton's It's All Relative considers the way in which Weinberg frequently casts his analyses in terms of relationships - as in the problem definition above - and derives from it a generalisation which he calls the relative rule:
 A description of something intangible as "X" really means "X, to some person at some time"
This gives us more variables to play with in any situation and so an approach to some problem might be to look at it from different time perspective or the viewpoint of a different person. He references a 1980s lecture by Jonathan Miller in which the ability of humour to alter perceptions of a scenario was proposed. A joke's punchline often hinges on revealing that what you thought you knew, or expected, was wrong.

Which lead me to ...

Laughing Matters, John Durant and Jonathan Miller (eds.)

Another collection of essays, the first of which is by Miller himself and covers the kind of ground that Bolton mentions. The copy I ordered arrived with perfect timing as I was preparing my proposal for EuroSTAR 2015, entitled Your Testing is a Joke, and dealing with the analogy I see between joking and testing. Try this short extract:
In all procedures of life there are rules of thumb which enable us to go on to 'automatic pilot' ... We depend on the existence of these categories in order to go about our everyday business. Jokes allow us to stand back from these rules and inspect them.
Yes. Yes. Yes. And testing too.

Agile Product Management with Scrum, Roman Pichler

The test team at Linguamatics services three different development teams working in different ways. Most recently, our Solutions team has started using Scrum and the SolDev Manager lent me this book. It didn't tell me much I hadn't already picked up from other reading, but it is clear, concise and readable for non-developers.


The Signal and The Noise, Nate Silver

One the Dev Manager lent me. In very roughly the same kind of area as Nicholas Taleb and dense, like Weinberg, although without the latter's easy style, this book was occasionally hard-going (for me) but worth persevering with. Each chapter is effectively self-contained so you can easily skip to the next chunk.

Silver tells a great story about Gary Kasparov and the chess computer Deep Blue in a series of high-profile matches in the late 1980s. In one game, the computer made an unexpected move which Kasparov noted and took time to analyse afterwards.

The only explanation he could come up with was that the move was motivated by a strategy that suggested Deep Blue was capable of looking ahead more than 20 moves.  This was unheard of and placed the computer at a significant advantage if true. Unfortunately for Kasparov, he subsequently acted as if it were true - attributing ability and chess wisdom to the software which adversely affected how he played against it - while in fact it was simply a bug.

Lauren Ipsum, Carlos Bueno

I was turned onto this one by a Testhead blog post. It's an Alice-like story about a girl who finds herself in a strange land populated by strange characters with strange ideas. The ideas come from computer science, although they are not presented that way in the story, and the characters include Hugh Rustic (oh yes, and there's plenty of other puns) who says, of the problem of buying tomatoes from the market:
 ... to find the best tomato, you'd have to compare them all, right? ... don't waste your time looking for the best tomato when there are plenty that are Good Enough.
I read it to my seven year-old daughter who loved it. We had some conceptually deep but still fun and fantastical discussions on the back of it and played with some Logo apps - the book features "poems" which are really Logo-style programs. I've now lent it to my mate to read to his son.


More Secrets of Consulting, Gerald M. Weinberg

Although I talked about Weinberg's writing in terms of icebergs earlier, this book is more like a tornado. It's a whirlwind of rules, parables, anecdotes and insight tied together by the concept of a Wisdom Box, or a toolkit for consultants. Here's one rule:
When a triangle separates you from your data, choose the hypotenuse.
For example, if X says that Y thinks something, and you care what Y thinks, confirm Y's position with Y before proceeding.

Agile Testing, Lisa Crispin, Janet Gregory

Which I've borrowed from one of my team on her recommendation but only just started.
Image: https://flic.kr/p/99NLP and the sites I've linked to for each book.

Comments

  1. Hi James,

    How are you? I came across your blog and I was wondering if you would be interested in guest blogging on TESTHuddle.com?

    In case you are unaware, TEST Huddle is a software testing community that was launched by EuroSTAR Conferences back in early 2014 and there has been steady growth of members ever since. Today we are proud to say that we have over 2500 members and counting.

    Adding a blog post to TEST Huddle is easy as we have an upload resource option available on the site. You can upload here: http://testhuddle.com/resources/upload-resource/

    The sooner you upload your blog, the sooner we could add it to the blog schedule.

    I look forward to hearing from you,

    Kind regards,
    Daragh

    ReplyDelete

Post a Comment

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

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

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

Postman Curlections

My team has been building a new service over the last few months. Until recently all the data it needs has been ingested at startup and our focus has been on the logic that processes the data, architecture, and infrastructure. This week we introduced a couple of new endpoints that enable the creation (through an HTTP POST) and update (PUT) of the fundamental data type (we call it a definition ) that the service operates on. I picked up the task of smoke testing the first implementations. I started out by asking the system under test to show me what it can do by using Postman to submit requests and inspecting the results. It was the kinds of things you'd imagine, including: submit some definitions (of various structure, size, intent, name, identifiers, etc) resubmit the same definitions (identical, sharing keys, with variations, etc) retrieve the submitted definitions (using whatever endpoints exist to show some view of them) compare definitions I submitted fro

Build Quality

  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 the build is green, the product is of sufficient quality to release" An interesting take, and one I wouldn't agree with in general. That surprises you? Well, ho

Make, Fix, and Test

A few weeks ago, in A Good Tester is All Over the Place , Joep Schuurkes described a model of testing work based on three axes: do testing yourself or support testing by others be embedded in a team or be part of a separate team do your job or improve the system It resonated with me and the other testers I shared it with at work, and it resurfaced in my mind while I was reflecting on some of the tasks I've picked up recently and what they have involved, at least in the way I've chosen to address them. Here's three examples: Documentation Generation We have an internal tool that generates documentation in Confluence by extracting and combining images and text from a handful of sources. Although useful, it ran very slowly or not at all so one of the developers performed major surgery on it. Up to that point, I had never taken much interest in the tool and I could have safely ignored this piece of work too because it would have been tested by

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

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

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