Hiccupps

  Over on the Agile in the Ether  Slack instance one of the Ethernets recently asked: MoSCoW: Does anybody have a simple way of explaining when items should be Must vs. when they should be Won't? Is it really as simple as whether it's an inclusion or an exclusion of the item? MoSCoW  is a basic approach to grouping project project work into buckets graded by priority: M: must have S: should have C: could have W: won’t have (for now) I'm sure every one of us has been in conversations where the buckets are filled and then stakeholders say they're all emergency-level important, but that's not today's problem. In this case the questioner had been burned by people twisting the words in unhelpful ways: " must not do ..." (i.e. won't) or " won't  do without ..." (i.e. must) which only makes the often fraught prioritisation discussions even less pleasant.  I have found MoSCoW to be useful so I share...

The theme at  LLEWT this year was Rules and constraints to ensure better quality.   My experience report concerned a team I'd been on for several years which developed (bottom-up) a set of working practices that we called team agreements.   The agreements survived "natural" variation such as people leaving and joining and even some structural reorganisation which preserved most of the team members but changed the team's responsibilities or merged in a few people from a disbanded team. The agreements did not, however, persist through a significant round of (top-down) redundancies where the team was merged with two others.  I'm interested in thinking about the ways in which constraints on how people work affect the work and whether there are patterns that could help us to apply the right kinds of constraints at times they are likely to be useful.  I'm going to use this post to dump my thoughts. My starting po...

A couple of months ago, in Can You Hack It? , I wrote about how I increased the testability of a service by changing it in a way that allowed me to simulate the behaviour of one of its dependencies. With that in place I could force specific code paths to be followed and so explore different scenarios easily. That was sufficient for a quick and dirty experiment but, because I was changing code, each round was slower than I'd have liked as I had to edit, compile, run, and then test. --00-- When the next opportunity to work in that area came up, on a different service, I looked for an improvement to my test approach. I realised that I could remove the compile-run step by having some configuration that would specify the response from the external service. So I taught our product to look for the URL of a downstream service in an environment variable every time it wanted to call it. This gave me very precise control of the outgoing requests which I pointed at a local mock server called ...

You Ain't Gonna Need It, YAGNI. A helpful tool to remind us to carefully consider building no more than we need to solve the problem in front of us. I see it mostly applied to software development questions but the same tension between investment cost, flexibility, and eventual value applies elsewhere and it's on my mind because I am thinking about two very different experiences with internal process. Without going into too much depth, there was an ancient process that my team ran infrequently and which had been slated for removal for a long time. At one point it had probably been a sleek and streamlined racing yacht but, by the time I encountered it, it handled like a barnacle-covered leaky skip.  Big changes, however, were always postponed in favour of more pressing concerns and, when I last worked my way through it, I found that a whole new outrigger had been bolted onto the side to support another process. It can be tempting to think of this crustiness as YAGNI at a kind of...

  A few months ago I stopped having therapy because I felt I had stabilised myself enough to navigate life without it. For the time being, anyway.  I'm sure the counselling helped me but I couldn't tell you how and I've chosen not to look deeply into it. For someone who is usually pretty analytical this is perhaps an interesting decision but I knew that I didn't want to be second-guessing my counsellor, Sue, or mentally cross-referencing stuff that I'd researched while we were talking. And talk was what we mostly did, with Sue suggesting hardly any specific tools for me to try. One that she did recommend was finding a happy place to visualise, somewhere that I could be out of the moment for a moment to calm disruptive thoughts. (Something like this .) Surprisingly, I found that I couldn't conjure anywhere up inside my head. That's when I realised that I've always had difficulty seeing with my mind's eye but never called it out. If I try to imagine ev...

I recall a time where I was moved to dig up this aphorism and share it with my colleagues: Poor planning on your part does not necessitate an emergency on mine. We chuckled because, naturally, your referred to other people and our planing was exemplary. It took me a minute or two to find a reference † because in my head the words were these: Your fantasy is not my emergency. Which I think I like better because it's more general and snappier.  However... I'm very conscious that it's easy to sound like a dick when rolling out a quote like these. It feels judgemental and won't move anyone up the team-player rankings, which probably explains why it doesn't get said much. But not being said doesn't mean not being thought and I've seen people think it a lot about project management, despite understanding that project management can be very, very, hard and that we generally aren't seeing the full picture. So, PMs, if yo...

It was Father's Day recently and one of my daughters made me a card which I love for all sorts of reasons, not least because it says she sees me practising "dad philosophy": See a need, fill a need Sadly this particular gem is not mine, it belongs to Bigweld , a character in Robots . We watched that film loads when my kids were little and I quoted it to encourage them to contribute to the chores, not ignore a mess, and look for opportunities to help each other out.  So I can't claim credit but, hat tip to Bigweld, it is a mindset I use for myself at home and take with me to work. Image: Robots Wiki

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-- "How can I possibly test 'all the stuff' every iteration?" Whoa! There's a lot to unpack there, so let me break it down a little: who is suggesting that "al...

Yesterday I was listening to an episode of Arts and Ideas hosted by Matthew Sweet. The topic was pranks and the first request he made of his guests was for a typology of the terms prank, hoax, stunt, and practical joke. No one was prepared to give one but, through the course of the programme, they clearly preferred one term over the others in specific instances or tried to bypass the distinctions by claiming that what mattered was whether there was a laugh. This is no great surprise. Categories invariably have fuzzy boundaries although, famously, we like to think that we can know where something belongs " when we see it ." My thoughts turned to work, and the problem of stakeholders using sets of overlapping terms when discussing what they want with no time for conversations about the meanings ("don't give me all that semantics!"). So I thought, on 1st April, I would take the fool's errand of trying to imagine working on a project where those concepts were ...

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

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-- "What's the best format for a test plan?" I'll side-step the conversation about what a test plan is and just say that the format you should use is one th...

This week I was working with a developer to make a change to a legacy codebase in an area neither of us are very familiar with. The need is easy to describe in general and some occurrences of the behaviour we want to alter are common, straightforward to identify in use, and clear in the code. Unfortunately, the logic in the application is complex, the data used is domain-specialised and the behaviour we are interested in can occur in extremely specific combinations that are hard for a layperson to predict. I had no confidence that cases we knew were all of the cases. My colleague did a round of work and asked me to take a look. I exercised the application in a few ways while inspecting its logs in real time so that I could see the effect of the changes (or not) immediately. This gave up some rarer examples which had not been covered in the code. I added a couple of tests to characterise them and he identified another code change. Next, rather than continue exercising the product lookin...

    A long stretch of a major route into Cambridge is being widened at the moment. To facilitate the work, one of the road junctions near my house was out of action for a long time and only reopened the other day. I didn't quite do a Laurel and Hardy comedy double-take as I walked past it for the first time, but I certainly took a second look. And a photo. Why? Because the triangle is painted the wrong way round and is, I think now that I've skimmed the regulations , too close to the double-dashed lines across the road as well.  In fact, it seems that the triangle may not even be required but, if it is used, it should look like the left-hand side here: Of course, we all occasionally mess up the simple job that we've done a million times before because we're on autopilot, or rushing, or doing something else at the same time. Understandable, but embarrassing and difficult to unsee or live down, particularly if there is a significant unwanted side-effect, such as a car cra...

  So much of what I want to do with automation is repetition of slight variants. I was reminded of it again last week when I was looking for a way to list the versions of certain dependencies across many versions of a product my team owns. These dependencies are exposed through the running product's API on an "about" endpoint. They can also be found in our Gradle configuration file, build.gradle , something like this: thingVersion = System.getenv( 'THING_VERSION' ) ?: '4.0' otherVersion = System.getenv( 'OTHER_VERSION' ) ?: '2.3.1' anotherVersion = System.getenv( 'ANOTHER_VERSION' ) ?: "7.6.0" Conceptually I need to run through released versions of the product, interrogate each for the  dependencies, and aggregate them into some easily-parsable format. If I was only after a couple of versions of the product I'd just check out the code for those versions, inspect the build.gradle files, and copy...