Skip to main content

Posts

We Actually Did Need It

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
Recent posts

Not a Happy Place

  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

Your Fantasy or Mine?

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

Lucky for Some?

  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

What the L?

  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 ov

Can You Hack It?

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

The Best Programmer Dan Knows

  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

Around the Testing World in 28 Ways

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

The Way to Test?

  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-- "Pair and ensemble testing look like a waste of time and resources to me. What do you think?" You're right! Sometimes.   But also not pairing or ensembling is a waste of time and r

Olivestrike!

The big story in IT right now is Crowdstrike 's unfortunate update that prompted millions of Windows machines to BSOD and caused chaos in critical infrastructure around the world. Actually, that's not just big, it's BIG or B. I. G. or maybe B! I! G! and it's provoked loads of speculation about the hows and whys and what-should-haves and what-didn'ts. But even on a week without that scale of fail, even on a week where nothing untoward happened on any computer anywhere, the observation I'm sharing here probably wouldn't merit much coverage.  This is it: Do you see? Just under the orange bar, the word OLIVE. Why? Don't get me wrong, I like olives. I just don't expect to see them on the BBC Sounds player while I'm setting myself up to listen to England win the cricket at the weekend. Of course, if you look a bit closer and wait a second or two, you'll see that there's a slight vertical alignment difference between the O and LIVE and the th