In the second hiding place I tied, and the evidence suggests I’m not the first to make my mistake. I dipped into this series on release day from the other “side”; now I’ve returned
(with my geopup pal) to do more of the loop! TFTC.
NHS England has issued new guidance to staff, which has been shared with New Scientist, that demands existing and future software be pulled from public view and kept behind closed
doors. “All source code repositories must be private by default. Repositories must not be public unless there is an explicit and exceptional need, and public access has been
formally approved,” says the new guidance. The deadline for making code private is 11 May.
Last month, an AI created by Anthropic called Mythos was widely reported to be capable of discovering flaws in virtually any software, potentially allowing hackers to break into
systems running it.
NHS England’s guidance specifically points to Mythos as the cause for the new measures.
…
Yet again, “AI” is the reason why we can’t have nice things on an open and transparent Web.
This is bad, of course. But the worst part is the illusion it helps feed that closed-source software is necessarily more-secure than open-source software. Obviously it’s all
much more-complex than that. Indeed, the article goes on to quote Terence Eden thoroughly debunking the entire line of thought:
“Is it possible that Mythos will scan a repository and find a bug? Yes, 100 per cent likely. Is that going to be a bug that causes a security issue in a live NHS service
somewhere? Almost certainly not,” says Eden. “I think it’s someone in NHS England buying into the hype that Mythos is going to cause the end of security as we know it and
getting a bit panicked.”
He’s right. This policy change is unlikely to improve the security of any of the affected pieces of NHS software (for much of which, the code is already out-there and archived, and so
removing it from the Internet now is pretty pointless). If it’s going to be attacked, it’ll be attacked, and the resources that the bad guys have for probing a whole
database worth of CVEs or fuzz-testing the extremities makes the availability of vulnerability-scanning AI pretty-close to irrelevant.
At least if it were open source then the good guys would have a chance of helping out… as well as we, the taxpayers who made the software possible, being able to see where our money was
going!
The Chicory House’s water meter, found in a cupboard, is so much easier to read than the one at our regular house, which is found down a frequently-flooded manhole on
the busy road outside.
Unfortunately, Thames Water had fucked-up1
and created an account for us already with the wrong information2,
so by the time I’d reached out to them they were already getting themselves into a pickle.
It turns out that, presumably because of some shortsightedness on the part of their software engineers, their computer systems wouldn’t let them change the information to
correct the problem. Nor could they simply delete the account and create a new one3.
Instead, the had to close the account they’d erroneously set up such that the start and end date of the contract was our moving-in date… and then set up
a new account starting from the day after.
Sigh. Fine! So long as it’s sorted, I didn’t even care. Until, that is, the bill arrived for the one day of the first (incorrectly-created) contract:
This looks pretty low for a metered water bill, until you realise that it covers a period of literally only eleven hours from us moving in (and taking a meter reading) until
the end of that day. And that during most of that time the water was switched-off because a pair of plumbers were installing a new bathroom!
That bill:
is for £13.16.
covers “9 April 2026 through 9 April 2026”, i.e. one day.
(which means that our estimated annual bill would be £4,803.40 (£13.16 × 365) – about eight times
the national average)
states that our account closure was/will be “04/09/2026” – the only date on the letter that’s in “short” date format and which would appear to be 4 September (in UK date format)
even though 9 April would make more sense (but would require interpreting it in US date format, which would make no sense).
Let’s see how that breaks down:
The rates are standard, albeit a little on the high end: Thames Water need to raise funds right now to fix all of the leaks in their pipes, apparently. What’s odd is the volume of
water they claim has been used.
According to this bill, we used three cubic metres of water between collecting the keys (at around 1pm), moving in, and taking a meter reading… and the end of the
day. That’s three thousand litres of water.
Is it possible to achieve that level of water usage in the nine hours of billable time that this bill covers? I guess, if you really tried, you could:
completely fill and then drain our 100-litre bathtub, three times an hour, taking a five-and-a-half minute bath in each before draining it again, for the rest of
the day4;
or
run the kitchen tap – the highest-pressure tap in the house – continuously for six hours and forty minutes; or
repeatedly flush all three toilets, on “full-flush” mode, once every 79 seconds until midnight5, for example.
Some science was involved in the writing of this blog post.
Obviously this is all ridiculous. I’m being ridiculous.
But then again, so is this bill, which claims that three adults spent 11 hours in a house and somehow used the amount of water that’s the recommended amount to drink in a day… by 1,500
adults. Despite the water being shut-off to install a shower and toilet for some of that time.
But then again, so is Thames Water’s computer system, which disallows the correction of mistakes even by their own staff and instead requires the creation of one-day contracts.
And also can’t decide which country’s date format to use. And, possibly, doesn’t allow them to obey data protection laws.
The whole thing’s ridiculous. Which I’ll be letting Thames Water know. Let’s see if they agree.
Footnotes
1 This may be no surprise to anybody who’s ever dealt with Thames Water before, or who
follows the news about their seemingly endless inability to keep clean water in its pipes and raw sewage out of our rivers, for example, while taking out loans in order to pay bonuses
to their self-back-patting executives.
2 They used information provided to them by the estate agent and failed to connect it to
the information they already had for us… which thanks to quirks of their information systems resulted in bigger problems down the line. Amusingly – and for a change! – none
of the problems were related to my unusual name, this time around.
3 Curiously, these initial mistakes on the part of Thames Water left them processing
personal information about me – an email address – that I’d never given to them, and allegedly unable to delete or correct it for six months after being asked to. This is the kind of
thing that normally gives me an excuse for a field day of DPA2018-related letter writing, but this time around I’ve been too busy dealing with the bigger problems they’ve
created to have a chance to stop and think about that: that’s how much of a mess they’ve made.
4 It’s only barely possible to repeatedly fill the bath this quickly, you need to use both
hot and cold water: the cold inlet alone doesn’t have the pressure to fill it fast enough, but the hot water tank has its own separate inlet which makes all the difference.
Also, a cold bath would suck, even if you’re only allowed five minutes in it before it’s time to drain the tub and start filling it again.
5 I once had a really rough night after a particularly dodgy curry, but I’ve never needed
to be flushing a toilet twice a minute for eleven hours.
This is a reply to a post published elsewhere. Its content might be duplicated as a traditional comment at the original source.
What’s the opposite of locked-in? Locked-open. Mwhahaa.
If only locked-open were easier for things that aren’t software. Like standards. And concepts.
If you’re developing software (like Mastodon), locked-open can be enforced by e.g. AGPL. You can change it, but you’re likely to have to share-alike.
If you’re developing standards (like RSS), locked-open can only be enforced by interoperability. If somebody wants to make a breaking change, they can… if they can make it popular
enough.
If you’re developing concepts (like podcasting), locked-open becomes a matter of principles. You and I might know that a “platform-exclusive” podcast is outside of the spirit of the
standard because it’s not distributed by an RSS feed to which anybody can subscribe.
But for these more abstract ideas, “locked-open” enforcement becomes a matter for education, optimism, and hearts-and-minds. And there are companies with huge resources that are willing
to fight against all of those.
why bother going to the brick-and-mortar store? amazon is more “convenient”. why bother cooking a nice meal for yourself? doordash and uber eats are more
“convenient”. why go out and socialize with people? facebook is more “convenient”. why use a digital camera, camcorder, or polaroid? your
smartphone is more “convenient”. why bother going to the theater or concerts? netflix and spotify are more “convenient”. why bother making art?
asking an AI to generate it for you is more “convenient”.
well, i say nuts to that. from now on, i’m going to make my life as inconvenient as possible. i’m going to go to the store and buy stuff in person. i’m going to make my own
food with my own hands. i’m going to socialize with people face-to-face. i’m going to use a true camera instead of my phone’s camera. i’m going to buy blu-rays, DVDs, and CDs
instead of streaming. i’m going to take my time when creating, watching, playing, and reading a work of art.
…
I’m seeing an growing movement in indieweb, revivalist, and adjacent circles that express RNotté’s sentiment: that the endless (and highly-marketable) quest for increased convenience in
our lives has gained us free time, but we’ve lost something along the way.
What we’ve lost varies from case to case, but includes freedom (from lock-in to subscription services), creative satisfaction (from convenient “artistic” expression), privacy (from
becoming the product, packaged-up by big-data advertising-funded tools), and social interactions (from so much of “social” media).
But reading RNotté share their thoughts on the matter today was the first time that it’s reminded me of The Matrix.
The connection was probably helped by the fact that I rewatched the film pretty recently.
There’s a bit where Agent Smith says, to his captive the rebel captain Morpheus:
Did you know that the first Matrix was designed to be a perfect human world? Where none suffered, where everyone would be happy. It was a disaster. No one would accept the program.
Entire crops were lost. Some believed we lacked the programming language to describe your perfect world.
Smith goes on to elucidate that his personal explanation for this fault was that humans depend upon suffering and misery, while acknowledging that there are other explanations. And
perhaps we’ve touched upon one.
Perhaps humans – all humans – have a limit for how much they’re willing to accept convenience as compensation. Connected humans in The Matrix grain a convenient life,
superficially superior to the struggle for survival experienced by humans living in the real world, short on food and hunted by machines. But to get that, they trade away their
individual ability to become aware of the truth and, collectively, the ability for humanity for shape its own destiny. But there’s something about the imbalance of power in the
arrangement niggles in human minds, and some rebel against the established order… and are joined by others who are shown that an alternative is available.
Clearly – as RNotté and others show – faceless technological forces need not go quite so far as enslaving an entire species before “convenience” no longer becomes a tolerable
mitigation!
I’m not convinced that seeking out inconvenience is in itself a good. But questioning what your conveniences are worth and what you’re paying for them… that’s definitely
worthwhile.
Me: Alright, let’s write a blog post about CSS.
🧠: Okay, but we need to make an entire design system first.
Me: That seems very complicated.
🧠: How long could it possibly take? 10 minutes?
Tell me about it.
I started a blog post about pedestrian crossings months ago and somewhere along the way I got bogged down with implementing a web component that uses 16-bit pixel art people
and cars to simulate and compare the relative throughput efficiencies of different timing systems and HELP I WENT TOO DEEP THIS WAS SUPPOSED TO BE A SIMPLE BLOG POST.
It’s been a long journey for our 9-year-old over the last four years, but today he is – going many others, mostly older and larger than him! – finally trying out for his recommended
black belt in taekwondo. 🥋 🤞
Checked up on this cache, this morning, as I was in the neighbourhood. It’s looking healthy, with dry contents including a sharpened pencil for logging plus a couple of tradables that
have turned up.
If you come find it soon then I hope the weather is as delightful for you as it was for us, today!
Folks at work have been encouraging to make more use of generative AI in my workflow1;
going beyond my current “fancy autocomplete” use and giving my agents more autonomy. My experience of such “vibe coding” so far has been… mixed2,
but I promised I’d revisit it.
One thing that these models are usually effective at is summarisation3. This is valuable if you’re faced with a large and unfamiliar
codebase and you’re looking to trace a particular thing but you’re not certain where it is or what it’ll be called. While they’re not always fast, these tools can
at least work in the background, which allows the developer to get on with something else while the agent trawls logs, code, and configuration to find and explain a
fuzzily-defined thing.
Recently, I had a moment which I thought might be such an instance… but it didn’t turn out quite the way I expected. Here’s the story4:
The broken dev env
I’d been drafted into an established and ongoing project to provide more hands, following a coworker’s departure last week. This project touches parts of our (sprawling,
microsevices-based) infrastructure that I hadn’t looked at before, so there was a lot I didn’t yet know.
I picked an issue that had belonged to my former colleague that QA had rejected and set out to retrace their steps: to replicate the problem that the QA engineers had identified and in
doing so learn more about the underlying process. I spun up my development environment and tried to follow the steps.
The process failed… but much earlier than QA had said it would. Clearly my development environment was at fault, or at least not representative of their setup.
But I couldn’t even get as far as their problem before my frontend barfed out an error message. Sigh! Probably there’s some configuration I’ve missed somewhere in the myriad
microservices, or else the data I’m testing with isn’t a fair reflection on what they’re doing as-standard.
Following some staff changes, I have no teammates on this side of the Atlantic who could help me decipher this: a “quick question on Slack” wouldn’t solve this one until hours
from now. It was time to start debugging!
But… maybe Claude could help? It’s got access to almost all the same code, logs, tools and browser windows I do. I started typing:
✨ What’s up next, Dan?
In my development environment for https://service.dev/asset/new, when I click “Save”, I see the error “Oops, something went wrong.”
Why?
Context is key
It’s quite possible that Claude would have gone away, had a “think”, done some tests, and then come back to me with a believable answer. It might even have been correct, and I’d have
been able to short-cut my way back to productivity (and I’d have time to make a mug of coffee and finish reading my emails while it did so). Then, I’d just have to check that it was
right, make the change, and get on with things.
But I realised that it’d probably work faster (and cheaper, and using less energy) if it had slightly more context from the get-go, so I elaborated. The first thing I’d
want to know if I were debugging this is what was actually happening behind the scenes. I dipped into my browser’s Network debugger and extracted the relevant output, adding it to my
prompt:
✨ What’s up next, Dan?
In my development environment for https://service.dev/asset/new, when I click “Save”, I see
the error “Oops, something went wrong.” Why?The payload POSTed to the server is { content: 'test1', audience: [ 'one' ], status: 'draft' } and
the response is a HTTP 500 with the following stack trace: pasted 94 lines
That’s more like it, now I could let it get on with its work. But wait…
Rubberducking
There’s a concept in computer programming called “rubberducking”. The name comes from an anecdote in The Pragmatic Programmer about a developer who, when stuck on a problem, would
explain the code line-by-line to a rubber duck. The thinking is that talking-through a problem, even to someone (or something) who doesn’t understand it, can lead the speaker to
insights they were otherwise missing.
I’ve done it myself many, many times: recruiting a convenient colleague or friend and talking them through the technical problem I was faced with, and inviting them to ask me to go
into greater detail if I seemed to be skimming over anything, and I can promise that it can work.
The panel above is part of a series in which a sorceress called Cepper who’s
coerced by her university into using Avian Intelligence (“AI”) – a robotic parrot5 that her headmaster insists is the future of magic. She experiments with it, finds it
occasionally useful but more-often frustrating, attempts to implement her own local version but find that troublesome in different ways, and eventually settles on using
an inanimate rubber duck instead. I get it, Cepper!
Let’s put that distraction aside for a moment and get back to the story of my broken development environment.
Clues in the stack trace
The top entry in the stack trace was an unsuccessful call to a different microservice, so I figured I’d pull its logs too, in order to further help direct
the AI in the right direction6:
✨ What’s up next, Dan?
In my development environment for https://service.dev/asset/new, when I click “Save”, I see
the error “Oops, something went wrong.” Why?The payload POSTed to the server is { content: 'test1',
audience: [ 'one' ], status: 'draft' } and the response is a HTTP 500 with the following stack trace: pasted 94 linesThe stack
trace suggests that a call is being made to the dojo backend service, where the following error log looks relevant: pasted 9
lines
I haven’t tried it, but I’m pretty confident that the LLM, after much number-crunching and a little warming-up of some datacentre somewhere, would get to the answer. But again, I found
something niggling inside me: the second-from top line in the dojo logs suggested that a connection was being made to a further, deeper microservice.
I should pull its logs too, I figured.
The final puzzle piece
As an aide mémoire – in a way I’ve taken to doing when taking notes or when talking to AI – I first typed what I was going to provide. This is
useful if, for example, somebody distracts me at a key moment: it means you’ve got a jumping-off point predefined by my past self:
✨ What’s up next, Dan?
In my development environment for https://service.dev/asset/new, when I click “Save”, I see
the error “Oops, something went wrong.” Why?The payload POSTed to the server is { content: 'test1',
audience: [ 'one' ], status: 'draft' } and the response is a HTTP 500 with the following stack trace: pasted 94 linesThe stack
trace suggests that a call is being made to the dojo backend service, where the following error log looks relevant: pasted 9
lines. It’s calling osiris, which says:
I dipped into the directory for
osiris, and before I even got to the logs I spotted a problem: that microservice was on an old feature branch. How odd! I switched to the main branch and… everything
started working.
The entire event took only a few minutes. I’d find some information, type it into Claude’s input field, realise that more information could be valuable, and repeat.
By the time I’d finished describing the problem, I’d discovered the solution. That’s the essence of successful rubberducking. I didn’t need the AI at all.
All I needed was the illusion of something that might be able to help if I just talked through what I was thinking.
I don’t know what the moral is, here.
I wonder if I’d have been as effective had I just typed into my text editor. I suppose I would have, but I wonder if I’d have been motivated to do so in the first place? I’ve tried
rubberducking before by talking to an imaginary person, but I’ve never tried typing to one7; maybe I should start?
Footnotes
1 I’m pretty sure every engineering department nowadays has it’s rabid fanboys, but I’m
pleased that for the most part my colleagues take a more-pragmatic and realistic outlook: balancing the potential benefits of LLM-assisted coding with its many shortfalls,
downsides, and risks.
3 So long as what you’ve got them summarising is something you can later verify!
4 I’ve taken huge liberties with the strict factual accuracy to make this more-readable as
well as to to not-expose things I probably oughtn’t. So before you swoop in to criticise my prompt-fu (not that I asked you, but I know there’s somebody out there who’s thinking about
doing this right now), please note that none of the text in this page are what I actually wrote to the AI; it’s a figurative example.
6 I’d had an experience just the previous week in which it’d gone off on completely the
wrong track, attempting to change code in order to “fix” what was ultimately a configuration or data problem, and so I thought it might be useful to give it some rails to follow, to
start with.
7 Except insofar as this AI agent is an “imaginary person”, which it possibly already a
step-too-far in implying personhood for my liking!
Imagine my surprise when the geohound and I are out for a walk from Appleton to find the Rainbow Bridge cache, to receive a notification of a new cache series at Northmoor. All we need
to do is extend our walk a short way, I figure, and we can claim an FTF!
But it was not to be! By the time the little doggo’s legs could carry her this far, we’d been pipped to the post. STF it is, then, after the joint victory just half an hour ahead of us.
And with that, it’s time for the pupper and I to turn around and head back to Appleton. Hopefully we can return to do the rest of this series sometime soon! TFTC.
Our taeget cache got the geopup and I: I’ve coated under this bridge, I think, but never found an excuse to go over it into today.
The doggo is running out of steam and the afternoon looks likely to be too hot for her, but we’ll make a quick run at one of the new Nortmoor Loop series before we turn back. Might even
score a FTF!
What a beautiful spot for a geocache, which the geopup and I quickly found in the second host we checked. Then, we enjoyed a delightful few minutes of peace, sitting on the riverbank,
before continuing our morning’s adventure.
The geohound wouldn’t let me search as long as I’d have liked, and my GPS must’ve been off because I couldn’t really find anything that matched the hint description. One for another
day, perhaps.