Hiccupps

Jerome Groopman, in How Doctors Think , reviews ways in which doctors can make poor choices, identifies potential causes, and suggests some practices, for both doctor and patient, that can help to prevent them. I find this interesting for a couple of reasons: first, I work in the health space, although not in a therapeutic area and, second, I like to reflect on my own thought processes. I'll take three broad themes from Groopman's analysis: the business of healthcare and how that impacts a physician's ability to practice; the doctor-patient relationship and how that impacts the experience of both sides; and the cognitive failings that impact a correct and timely diagnosis for any given patient. Naturally, these overlap. The book is written from the perspective of the notoriously commercialised American medical system and is around 20 years old, so doubtless some of the details are different outside of the US and have changed since pu...

  I told you how much I love Kill it with Fire by Marianne Bellotti in This is Fire and you can see it in my copy above too. It's a book about dealing with legacy systems but in the first couple of chapters grounds its thesis in the marketplace, thinking about how products, the constraints on them, and the context in which they sit change in controllable and (more often) uncontrollable ways. This might not seem very "tech" but in fact is fundamental to understanding how we seem to bounce back and forth between the same kinds of solutions, why some of them become legacy, and why we should think carefully about radically changing a working system. To be clear, this information is not necessary to get the core benefits of the book but I found it fascinating and wanted to try to triangluate concepts such as Alignable and non-alignable differences Service-dominant Logic Hype Cycle Unique Selling Proposition Cro...

  Kill it with Fire is ostensibly a book about legacy systems but is packed with good advice about managing any significant project. In one chapter Marianne Bellotti talks about gathering consensus, showing progress, and maintaining momentum. It's probably coincidental but she happened to use several words that start with "pr" when describing some of the key aspects of her approach. I liked the description a lot, but I also liked the pun, so I recast the broad ideas with a Public Relations head on: Provoke a need. You'll have observed that people tend to care more about urgent than important. What urgent hook can you hang your important project on? Is there a security issue, a performance issue, a cross-team ambiguity, or anything else that can be used to motivate others?  Promote the value of the project to whoever matters and will listen. Be prepared to cast the value in their terms rather than yours. The head of marketing doesn't give a crap about your tech de...

    Kill it with Fire is by Marianne Bellotti is a truly awesome book about dealing with legacy systems. If you're in software you need to read it and this high-level summary is my attempt to persuade you to do that, right now. What is legacy software? an existing system, onboarding is probably hard because of its age, design patterns are probably consistent but out of date, it will probably still scale if the infra scales.  (Note that tech debt generally isn't legacy by this definition, although that doesn't matter. Much of the book is relevant to both.) How do we end up with legacy software? Choices made over time, decisions that seemed pragmatic, unexpected or undesirable constraints, re-orgs, accidents, compromises, ...  Why do we seem so keen to throw legacy software away? Because writing is easier than rewriting, because we bias to see only the positive possible outcomes, because we can try our ...

In Obliquity , John Kay argues that success may be best achieved indirectly. When the goal is non-trivial, the environment unpredictable, and the system in which we are operating is complex, then top-down working, planned to completion, is fragile. He recommends that we instead proceed obliquely , taking small steps, making choices opportunistically, and accepting that we do not have all the information or all of the control we might feel we want. Kay presents numerous examples of people and organisations that have done well with the oblique approach and some that have suffered when their indirect strategy straightened up. That's not to say the direct approach can't work or that it is a mistake to apply it to some situations, just that the set of real-world scenarios where directness is a good first choice is pretty constrained. It doesn't take much imagination to see the strong parallel between obliquity and agile software development. Likewi...

I'm reading Rick Rubin's The Creative Act: A Way of Being . It's spiritual without being religious, simultaneously vague and specific, and unerringly 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...

    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 ...

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 eff...

I've just finished How to Cheat at Everything by Simon Lovell. It's a good read, although the lengthy descriptions of false cuts, dodgy deals, and ways to conceal or peek at what you shouldn't during high-stakes card games got repetitive.  In fact, at some level the whole book is extremely repetitive: there is always somebody looking for an angle and if you're the producer, consumer, or user of anything you are a potential target. Sometimes the angle is knowledge. Being aware of, or being able to calculate, probabilities will protect against some scams, such as those at the fairground or in amusement arcades. In them the punter is lured in through social engineering to play a game they will never win. That's not to say they won't get some return, of course, just that its value will be minuscule relative to the cost. Sometimes the angle is ambiguity. Bar bets are essentially riddles for money and the setup will make them sound like a sure win for the punter....

    Yesterday, reading The Year Without Pants by Scott Berkun, this leapt off the page at me:  Diversity of skill makes people self-sufficient. It's in a paragraph about the culture at Automattic, the people behind WordPress, when Berkun worked there around a decade ago. The paragraph continues: "They didn't need much help to start projects and were unafraid to learn skills to finish them ... They weren't afraid to get their hands dirty in tasks that in a mature engineering company would span the turf of three or four different job titles. That lack of specialization made people better collaborators since there was less turf to fight over." Last week at work I observed that my team's build pipeline was broken. I do not enjoy investigating this kind of infrastructure problem. The company Jenkins setup has a complex ecosystem with many moving parts, my mental model of how all the bits are interconnected is fuzzy, and in any case all the bits keep changing. The ...

  Over on the Association for Software Testing Slack our book club facilitator, Zenzi Ali , is guiding us through Elisabeth Hendrickson's Explore It! Last week she posed this question: "When joining a new team/job/project, how do you determine the core capabilities of the software you’ll be testing?" I surprised myself a little with my answer. Not because of what I described, but because I hadn't mapped it out this way before. It was only when I stepped back to try to summarise that I noticed the pattern in my intuitive behaviour. So here's what I wrote, edited so that it's less of a stream of consciousness. --00-- Rob Meaney has a great talk, A Tale of Testability , where he describes how his CODS criteria (controlability, observability, decomposability, simplicity) were applied to a product he worked on to make it more testable.  Now, I'm not suggesting that someone walks into a new team and shouts about re-engineering for testability before they...

  The Great Post Office Scandal by Nick Wallis is a depressing, dispiriting, and disheartening read. For anyone that cares about fairness and ethics in the relationship that business and technology has with individuals and wider society, at least. As a software tester working in the healthcare sector who has signed up to the ACM code of ethics through my membership of the Association for Software Testing I put myself firmly in that camp. Wallis does extraordinarily well to weave a compelling and readable narrative out of a years-long story with a large and constantly-changing cast and depth across subjects ranging from the intensely personal to extremely technical, and through procedure, jurisprudence, politics, and corporate governance. I won't try to summarise that story here (although Wikipedia takes a couple of stabs at it ) but I'll pull out a handful of threads that I think testers might be interested in: The unbelievable naivety which lead to Horizon (the system at th...

  In episode three of Oddly Influenced, jUnit and What Makes a Successful Tool , Brian Marick is speculating about the relative lack of adoption of test-driven development compared to the tooling that supported it.  After putting forward a particular theory he wonders whether it's "true" and says: That ... gives me an opportunity to state a theme that’s been in my work for decades. I read books ... about how people do their work. I’m not so concerned if the theories are true as if they are suggestive – that is, do they give me ideas about how software people should do our work. [The] next task is trying out whether those ideas have good results, in our work. Because everyone’s theory about people is somewhere between fully wrong and fully right, and is always incomplete. I like this perspective a lot. It puts me in mind of Paul Feyerabend's Against Method, a book I failed to finish because it was so dense and widely-read, bu...

Zenzi Ali has been running a book club on the Association for Software Testing Slack and over the last few weeks we've read Agile Testing Condensed by Janet Gregory and Lisa Crispin. Each chapter was taken as a jumping off point for one or two discussion points and I really enjoyed the opportunity to think about the questions Zenzi posed and sometimes pop a question or two back into the conversation as well. This post reproduces the questions and my answers, lightly edited for formatting. --00-- Ten principles of agile testing are given in the book. Do you think there is a foundational principle that the others must be built upon? In your experience, do you find that some of these principles are less or more important than others?  The text says they are for a team wanting to deliver the highest-quality product they can. If we can regard a motivation as a foundational principle, perhaps that could be it: each of the ten pr...

A month or two ago, after seeing how I was taking notes and sharing information, a colleague pointed me at Tiego Forte's blog on Building a Second Brain : [BASB is] a methodology for saving and systematically reminding us of the ideas, inspirations, insights, and connections we’ve gained through our experience. It expands our memory and our intellect... That definitely sounded like my kind of thing so I ordered the upcoming book, waited for it to arrive, and then read it in a couple of sittings. Very crudely, I'd summarise it something like this: notes are atomic items, each one a single idea, and are not just textual notes should capture what your gut tells you could be valuable notes should capture what you think you need right now notes should preserve important context for restarting work notes on a topic are bundled in a folder for a Project, Area, or Resource and moved into Archive when they're done. ( PARA ) ...