Hiccupps

In What We Know We Don't Know , Hillel Wayne crisply summarises a handful of research findings about software development, describes how the research is carried out and reviewed and how he explores it, and contrasts those evidence-based results with the pronouncements of charismatic thought leaders. He also notes how and why this kind of research is hard in the software world. I won't pull much from the talk because I want to encourage you to watch it. Go on, it's reasonably short, it's comprehensible for me at 1.25x, and you can skip the section on Domain-Driven Design (the talk was at DDD Europe) if that's not your bag. Let me just give the same example that he opens with: research shows that most code reviews focus more on the first file presented to reviewers rather than the most important file in the eye of the developer. What we should learn: flag the starting and other critical files to receive more productive reviews. You never even thought about that possi...

Some friends of mine are talking about starting to blog. They know why they want to blog, they have topics to blog about, and they are thoughtful, experienced, and eloquent enough that I have no doubt their writings would be worth reading. However. However they have been talking about starting for a reeeeaaaalllly loooooooong time.  Now, for sure, talking is good. Externalising ideas and goals to people you trust can provide a reality check, be a source of encouragement and refinement, and perhaps even feel like a commitment and motivation to start. But. But talking isn't actually starting . Now, for sure, they have reasons for not actually starting. Can't decide which platform to use, can't decide whether it should be testing or more general, need to think of a name, ... Nevertheless. Nevertheless those are displacement activities. They are completely valid, and even important, to consider but not needed in order to draft a first post. Perhaps you are prevaricating about b...

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