Hiccupps

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

  This month marks 13 years of Hiccupps and this is the 660th post.  It's traditional for me to mention in my anniversary posts that, when I started the blog, I tested my interest in blogging by challenging myself to write around a post a week for year. I usually then also say that I'm amazed I've kept that rate up in the intervening years. This year is no exception, although I am particularly surprised because my personal life is getting increasingly difficult and I am finding less time and energy for blogging. A non-surface glance at the numbers reflects this: 40 weeks into 2024 and 24 posts. If I cared about such things, I might worry that Blogger's unreliable numbers suggest that someone (or more likely some thing ) is visiting more as I do less. But I don't care. Instead, as I look at this graph my testing head wonders whether this possible inverse relationship would mean that I could get a very large number of views by re...

  The other day my dad showed me a copy of my BSc. dissertation that he's had in a folder somewhere since 1992. I remembered vaguely that it was about drawing trees and plants using L-Systems   to describe the structures and Logo to render them, but had no strong memory of what I actually did. Flipping through it, I saw that I learned enough C , yacc , lex , and Postscript to cobble an implementation together and that the trees, although only greyscale line drawings, could model aspects of natural growth patterns in a convincing way. A pleasant trip down memory lane, for sure, until a what the ...? moment as I came across a (short) section on testing. I have no recollection of learning testing at university and there are no testing resources in my bibliography. Did I just make it up as I went along? Well, as we all know, anyone can test, so I thought I'd look at what approaches the anyone who was the callow me tried. I pulled out evidence from the brief text, trying not to o...

Why wouldn't you just give up? The system under test has poor testability which means that the testing you'd like to do will take longer and the resolution of your findings will be lower than you'd like. So do you give up, battle through, wait for someone to add what you need ... or change the product yourself ? There are potential risks to that last option, of course, because (duh!) you're changing the product. But there are potential wins, too, because you're getting the data you want earlier and can give richer feedback to your stakeholders. I took that route this week.  The service I'm looking at is essentially a pipeline of steps, each of which calls out to a third-party service and post-processes the result, set up like this: result1 = step1.run(input) result2 = step2.run(result1) result3 = step3.run(result2) I wanted the response time for a large number of requests against its API, which I can get easily from the client ...

  I was pairing with my friend Vernon at work last week, on a tool I've been developing. He was smiling broadly as I talked him through what I'd done because we've been here before. The tool facilitates a task that's time-consuming, inefficient, error-prone, tiresome, and important to get right. Vern knows that those kinds of factors trigger me to change or build something, and that's why he was struggling not to laugh out loud. He held himself together and asked a bunch of sensible questions about the need, the desired outcome, and the approach I'd taken. Then he mentioned a talk by Daniel Terhorst-North, called The Best Programmer I Know, and said that much of it paralleled what he sees me doing. It was my turn to laugh then, because I am not a good programmer, and I thought he knew that already. What I do accept, though, is that I am focussed on the value that programs can give, and getting some of that value as early as possible. He sent me a link to the ta...

The Association for Software Testing has been crowdsourcing a book, Navigating the World as a Context-Driven Tester , for the last three years. Over that time 28 questions or statements about testing have been posed to our community and the various answers collected and collapsed into a single reply. Lee Hawkins, the coordinator of the project, has just blogged about the experience in The wisdom of the crowd has created an awesome resource for context-driven testers . He pulled some statistics out of the records he's kept showing the level of interest in each question or statement, measured by the number of responses from the community. That's the red bars on the chart at the top, ranging in value from 4 to 28. I replied every single time Lee posted, with a very specific mission in mind: 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 fa...