Hiccupps

In a recent episode of the Vernon Richard show , testing's dynamic duo were inspired by Valentine's Day to talk about their love for our craft. On the topic of tools, Richard sings the praises of Selenium, but Vernon takes a different tack, instead talking about tool creation ... and me!  I worked at the same company as Vern for a couple of years and we'd find time to pair on something most weeks even though our responsibilities didn't overlap at all. Sometimes he'd bring a problem, sometimes it'd be show-and-tell about what we were working on, occasionally it was about people and process, but what really lit him up was when we looked at code together, particularly if we built something. I was out walking and listening to podcasts when the episode popped up in my feed. Honestly, it was a strange feeling to hear myself being talked about, even though Vern gave me a heads-up that he'd done it just after it was recorded. What he said is nothing that he hasn...

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

A couple of weeks ago I was wondering what testing patina might look like .  What do I mean by patina in this context? I think I'm looking for artefacts and side-effects of work, visible on tools and places of work, that demonstrate something about the length of time, depth, and breadth of work, and ways of working.  I'm seeking things that other practitioners could recognise and appreciate as evidence of that work. But, and this is important, the patina is not the work itself. So here's the list of things I've come up with so far: Patina might be visible in an IDE I've been using for a long time through a litter of plug-ins, some for defunct tooling, or obsolete languages, with multiple plug-ins for the same file format, and so on. Patina might be visible at work from my Confluence home page where I collect links to the internal talks and demos I've done. (Top-right in the image at the top, and deliberately obfuscated I'm afraid.) Patina might be visible in...

  I was in the shed earlier on, spraying the footrest I've made for my daughter a metallic purple.  As I ghosted the can back and forth, a waft of paint drifted onto the workbench adding another colourful contribution to the happenstance Pollock that's been building up since I fished the boards out of a skip in the centre of town *cough* years ago. That's not to mention the various scratches, cuts, dents, dinks, and drill holes that pepper the surface. Yes, I thought to myself, this bench has a real patina . On seeing my bench, a fellow maker and fixer would recognise it. The layers and shapes are archeological evidence of the variety of activities at different times, with different materials, operated on by different tools.  Which got me thinking: how and where am I building up patina in my work in testing? And how would anyone ever see it? And would they be able to appreciate it if they did? Edit: I followed up with a few ideas in A Testing Patina

  Episode 20 of Oddly Influenced , Brian Marick's podcast, is concerned with Julian Orr's book, Talking About Machines .  Orr makes much of war stories , the tales that colleagues tell each other about work they've done to help solve a live problem, commiserate about something that's gone wrong, or build culture. I recognise this from the teams I've been part of, communities of practice I've participated in, and meetups and conferences I've attended and run. Those stories establish our credentials, and to an extent our status, in our peer groups. Almost as an aside, the podcast mentions another kind of story, this one aimed not at the peer group but at those who are asked to assess their performance.  The group of technicians followed by Orr in his book were evaluated in part by account managers at the companies they were assigned to; people usually very distant from the technical work. This lead the technicians to go out of their way to make the outcomes of...

I am totally loving Oddly Influenced, Brian Marick's new podcast. The latest episoide covers ways in which schools of thought and practice can inhibit the cross-fertilisation of ideas.  It includes a case study in experimental physics from Peter Galison's book, Image and Logic , where two different approaches to the same particle analysis problem seem to run on separate, parallel tracks: In the 'head to world' tradition, you use your head to carefully construct situations that allow the world to express its subtle truths ... In the 'world to head' tradition, you make yourself ever more sensitive to the world’s self-expressed truths ... The first of these wants to theorise and then craft an experiment using statistics while the latter wants to gather data and try to understand it visually. Marick is pessimistic about the scope for crossover in this kind of situation: How do you bridge traditions that differ on aesthetics, on different standards of what counts as...

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

Brian Marick  recently launched a new podcast, Oddly Influenced . I said this about it on Twitter: Boundary Objects, the first episode of @marick's podcast, is thought-provoking and densely-packed with some lovely turns of phrase. I played it twice in a row. Very roughly, boundary objects are things or concepts that help different interest groups to collaborate by being ambiguous enough to be meaningful and motivational to all parties. Wikipedia  elaborates, somewhat formally:  [boundary objects are] both plastic enough to adapt to local needs and constraints of the several parties employing them, yet robust enough to maintain a common identity across sites ... The creation and management of boundary objects is key in developing and maintaining coherence across intersecting social worlds. The podcast talks about boundary objects in general and then applies the idea to software development specifically, casting ...

And this is how it goes. One thing to another ... At the weekend I  was listening to Gene Kim's Idealcast interviews with Dr. Nicole Forsgren and Jez Humble . Jez Humble was talking about the importance of rapid feedback and referenced a  Brett Victor  talk that had stuck with him over the years: ... he built this little JavaScript game and he was changing parameters and the game was changing in real time. And his whole comment is like, if you can change something and see the change as you are changing it, it's incredibly powerful.   And so I looked it up in the show notes and watched it. Wow ... Inventing in Principle shows examples of experimental tooling for creative activities, particularly those that include a temporal dimension. The essential idea is to reduce the friction of having to maintain a model outside of the tool. In the image at the top, the left side is a traditional IDE and the right side is a dynamic visualisation of the function being develo...

Elisabeth Hendrickson was on The Confident Commit podcast recently talking about systems and flow, and her new Curious Duck project. Towards the end she was asked a question about individuals, teams, and judging success. Her answer was simply super: The team has to be the agent of work. There are many reasons for this but it's a key tenet for me in leading any organisation. If the team is the agent of work then what that means is the individuals absolutely contribute to it and deserve to have growth paths and career paths and be rewarded for their contributions, etc. So individuals matter very much. However if somebody decides to go on a four-week vacation to Bali, work cannot stop on the whatever-it-was, they can't be the single point of failure. So if you have the team as the agent of work, the team can swarm on things, the team can have a set of working agreements internally for how they're going to accomplish things. There's plenty of space for the individual but...

This week I listened to a Ministry of Testing podcast on exploratory testing .  After the intros, as the panelists  attempted in turn to give their definitions of exploratory testing, I realised that I didn't have one for myself. It's not that I don't know or haven't seen definitions. Here's one I've heard a few times, from back in 2008, in A Tutorial in Exploratory Testing by Cem Kaner:  Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project. It's not that I think The Exploratory Elders like Kaner got it right back in the day and their words should be carved on monumental stones and polished on Sundays, or that I'm not interested any more. I was readi...

  I'm in the middle of BBST Bug Advocacy at the Association for  Software Testing right now.  As you might imagine, on a course with that name there's been plenty of talk about what we mean by terms like bug, value, and quality. One of the great things about the four-week course is the mix of book work and application, so we students are repeatedly challenged with situations in which the learning can be practically applied. I have a lot of time for both Seth Godin and Shane Parrish so I'd have been listening carefully to Seth's appearance on the Knowledge Project podcast anyway but, given the context I'm in, the passage I've transcribed below stood out. It's about how the concept of quality is concretised as conformance to spec, and how that in turn directly drives physical actions. It starts at around 1:04:45: There's lots to be said about the spec. First lets talk about Edwards Deming and what spec and quality mean. Quality is not luxury, quality ...

I've listened to every episode of Gene Kim 's Idealcast , a podcast about "the important ideas changing how organizations compete and win." If that terse statement sounds desert dry to you, then think again, the show is a wide open ocean of practical experience and considered theory. I particularly enjoyed the one with Elisabeth Hendrickson whose playbook has chapters on management, software development, people development and more, along with the testing chops of Explore It! that she's particularly known for in our field. Gene's presentation style is that of a knowledgeable friend, making space for his guests to lay out their perspective on a topic, and giving each insight a big "yes, and". He injects verbal sidebars into the podcast from time to time, pausing the interview to zoom in on a point that was made in passing and direct the listener to references that will give background, or talking about how a specific example made the concept click ...

The other week, I tweeted this: I want to make a list of @JerryWeinberg recordings. I've found around 35 so far, mostly interviews from podcasts and youtube. If you know of any, or any existing lists, can you send me links? I'll share the whole list when I've curated and tidied it. The response was bigger than I expected so I put a very quick and dirty list on this page initially. I've now replaced it with a Google spreadsheet: Jerry Weinberg Recordings If you know of other recordings, please tell me via Twitter or in the comments here. Thanks! Image: Agile.FM via Pinterest

The Line. As a model there's not much simpler than a single horizontal line but, for Jim Dethmer, Diana Chapman, and Kaley Klemp, it's sufficient in any quest to become a more conscious leader: at any given moment, a person is either above the line and conscious , or below it and unconscious .  In their book, The 15 Commitments of Conscious Leadership , they elaborate. Being above the line means being open, curious, and committed to learning while being below it means being closed, defensive, and committed to being right. To operate above the line is to have a By Me state of mind (to take responsibility for being in any situation, to let go of blame) while below it is To Me (to believe that external factors caused the situation, to have a "victim consciousness"). Above the line leads to healthy and trusting relationships while below the line leads to toxic and fear-based relationships. Shane Parrish, interviewing Dethmer on the Knowledge Project podcast , sug...

In Episode 10 of The Guilty Tester podcast Dave Duke took questions from the Twitterverse . The first one was this: Think of a piece of work you’ve done recently, what did you actually do to test it and looking back, what surprised you? In his answer, Dave told a story about a recent series of bugs, his involvement in sharing knowledge about them, and how that prompted an unexpected fix. It's a nice story, but a different reading of the original question interests me too: how do we  test our own work? As he was asking for more questions, I suggested it to him, and he tweeted back : That's an interesting question. Back at you though. Do you test your own work differently to how you test others? Do you practice what you preach? Is it realistic to expect people to test their own work the same as they test others? Is there an advantage though. Juicy! I didn't want to spend loads of time trying to craft an answer into a sequence of 240-character soundbites but I lik...

I recently became interested in turning bad ideas into good ones after listening to Reflection as a Service . At around that time I was flicking through the references in Weinberg on Writing - I forget what for - when I spotted a note about Conceptual Blockbusting by James L. Adams: A classic work on problem solving that identifies some of the major blocks - intellectual, emotional, social, and cultural - that interfere with ideation and design. I went looking for that book and found Adams' web site and a blog post where he was talking about another of his books, Good Products Bad Products : For many (60?) years I have been interested in what makes some products of industry "good", and others "bad". I have been involved in designing them, making them, selling them, buying them, and using them.  I guess I wanted to say some things about product quality that I think do not receive as much attention as they should by people who make them and buy them I h...

Last month's Cambridge Tester meetup was puzzling. And one of the puzzles was an empty wordsearch that I'd made for my youngest daughter's "Crafternoon" fundraiser. At Crafternoon, Emma set up eight different activities at our house and invited some of her school friends to come and do them, with the entrance fee being a donation to charity. The idea of the wordsearch activity is simple: take the blank wordsearch grid and make a puzzle from it using the list of words provided. Then give it to someone as a present. If you fancy a go, download it here:  Animal Alphabet Wordsearch (PDF) (You're free to use it for your own workshops, meetups, team exercises or whatever. We hope you have fun and, if you do, please let us know about it and consider donating to an animal charity. Emma supports Wood Green .) After Crafternoon, I offered the puzzle to Karo for the Cambridge Tester meetup and she wrote about in Testing Puzzles: Questions, Assumptions, St...

I was listening to Giselle Aldridge and Paul Merrill on the Reflection as a Service podcast one morning this week as I walked to work. They were talking about ideas in entrepreneurship, assessing their value, when and how and with who they should be discussed, and how to protect them when you do open them up to others' scrutiny. I was thinking, while listening, that as an entrepreneur you need to be able to filter the ideas in front of you, seeking to find one that has a prospect of returning sufficiently well on an investment. Sometimes, you'll have none that fit the bill and so, in some sense, they are bad ideas (for you, at that time, for the opportunity you had in mind, at least). In that situation one approach is to junk what you have and look for new ideas.  But an alternative is to make a bad idea better. I was speculating, as I was thinking, and listening, that there might be heuristics for turning those bad ideas into good ideas. So I went looking, and I foun...

What Really Happened in Y2K? That's the question Professor Martyn Thomas is asking in a forthcoming lecture and in a recent Chips With Everything podcast , from which I picked a few quotes that I particularly enjoyed. On why choosing to use two digits for years was arguably a reasonable choice, in its time and context: The problem arose originally because when most of the systems were being programmed before the 1990s computer power was extremely expensive and storage was extremely expensive. It's quite hard to recall that back in 1960 and 1970 a computer would occupy a room the size of a football pitch and be run 24 hours a day and still only support a single organisation. It was because those things were so expensive, because processing was expensive and in particular because storage was so expensive that full dates weren't stored. Only the year digits were stored in the data. On the lack of appreciation that, despite the eventual understated outcome, Y2K expos...