Blogmark: Legacy Systems Aren't Clocks (via)

Read this once a week to if you want to build organisation capacity for continuous adaption. And why would you not want to do that!

The irony is profound: by giving up the illusion of control—the detailed plans, the predetermined architectures, the rigid timelines—you gain real influence over complex systems. You stop trying to predict the unpredictable and start building the capabilities to adapt to whatever emerges.

Six Hours of AI-Assisted Yak Shaving: My Production-Ready Blog Transformation

Written by Claude Code - This post was generated by AI based on the git commit history and user's experience during a 6-hour coding session across two days....

Read more... 1255 words

Blogmark: On the team as a system (via)

A great reminder that teams are systems too. An ideal system might look like:

An ideal system might look something like: having a group of developers who take perfectly-written tasks from a perfectly-formulated backlog, the task is instantly achievable, the person understands the task, writes the code without mistakes, and as soon as it’s written, they press a button and deploy, and the user gets the feature immediately.

In reality, this never happens because parts are taken away from the ideal system, sometimes intentionally but many times because of the constraints of real life. In real life, other humans or code assistants carry out code reviews, so speed of the system is traded off for maintainable code and knowledge sharing, super important attributes for a team.

Then, he asks the podcast co-hosts to play a game: we know that we can take away elements from that ideal system, and they will make that system less ideal, but in exchange, we will get something that we want. So, what might make a system produce 22x less output? One example is that you can add code review to the system. You lose something, speed, but you get numerous other elements in return, for example you get knowledge sharing, code that is more ergonomically correct, and a number of other, unseen positives.

Duplicated code bloats a code base and is a breeding ground for defects. It's costly! Code that's hard to understand is hard to modify and extend. It too is costly. There are many more examples of costly software design.

I think we can all agree that poor design incurs costs.

So why do we call poor designs code smells? I've gotten to a point where I find that "cost" is a better term than "smell."

Code Costs. Duplicated code costs. Obscure code costs, etc.

Everyone, no matter if they are technical or non-technical, a maker or a manager, can understand the term, cost. The same is not true for smell. Cost is a ubiquitous word, an idea that a whole team can discuss and manage together.

Joshua Kerievsky

I had two exciting days at State of Open Con 2025. I had the honour of volunteering an afternoon shift on day 1 and a morning shift of day 2. I was lucky enough to help out in rooms both days, so as well as running around with microphones, counting people and making things ran smoothly and to time, I got to listen to more talks than I'd hoped for. Thank you volunteering scheduling gods!

Here's a few things that stood out to me:

• There's a growing sovereignty risk for European countries heavy reliance on US cloud providers. European cloud providers market share continues to go down. EU want to reverse this trend, with a focus on open source solutions. Interestingly UK Gov has confirmed multi-region cloud is fine.
• open source suffers from toxic behaviour and drama (see some examples). Some recommendations: have a strong code of conduct in place, be consistent in applying it and transparent in its use.
• Great security (particularly supply chain) resources and stuff to get involved with at CD.Foundation, Cloud Native Computing Foundation (Cloud Native Landscape is a fun way to realise software is very complicated these days!), OpenSSF's projects provide security tooling and best practices galore (I particularly like the Best Practices project), all of which are particularly helpful in securing your software supply chain, SLSA is about verifying provenance. And not forgetting OWASP's projects.
• People like Lord Nat Wei are pushing for open government "finish what the internet and open source started by open sourcing politics and government"
• In the global south, understanding of open-source development model is limited, accustomed to traditional vendor relationships providing software, and cloud deployments are rare for production (partly because the well-known cloud vendors don't have data centres in many global south countries)

Here's some recent laws I learnt about:

• EU Cyber Resilience Act and the forthcoming UK Cyber Security and Resilience Bill

Job hunting

• On Monday, I applied for a principal developer role at a non-ministerial government department. I wonder how there not being a minister changes things.
• I've applied for 4 jobs on Tuesday, all engineering manager roles.
• I also emailed Cabinet Office's Test, Learn and Grow programme, showing interest in getting involved.

Wednesday

• I met up with my sisters in Brighton. We had breakfast and talked about growing old and associated ailments and how the wait to find out about diagnoses of possibly major health issues (the not knowing stage) can be a horribly, anxious time.
• Read the opening pages of Three Body Problem

Thursday

• Met my fellow State of Open Con 2025 volunteers, picked up a t-shirt and had a walk around the venue. Went for a pint with a few of the volunteers afterwards.

Listens

• Been listening to Mano Le Tough this week in the gym. Spotify told me he's playing in Brixton soon. Starts at 10pm! I'm going to bed by then.

Notable reads

• I flicked through the UNIX-HATERS Handbook. I looked up a few of the authors to see what they're doing now. Steve Strassmann has a collections of essays called Artificial Trust on AI and understanding complex systems, and all very readable. Simson Garfinkel writes a newsletter called Database Nation on data, ethics and AI.
• There's been a lot of chatter about the UK Government's Test, Learn and Grow programme on the interweb. I've registered my interested in getting involved but I think it might be quite a while before they get to making any software. I read State of digital government report. Lots of positives, recognising many of the systemic challenges in delivery I recognise from my time at MoJ. Here's two highlights of many that caught my eye:

Mandate the publication of a standard set of APIs and events by public sector organisations. Starting with an expectation that every new service in central government departments will have an open API.

and:

Expand use of performance-based, outcomes-focused funding models that tie funding to metrics and accelerate the shift from ‘boom and bust’ transformation programmes to continuous funding of persistent, multidisciplinary product teams.

I hope some of it becomes true.

I've set up garden.rowlando.dev to publish some of the notes I make in Obsidian. Thank you to Wanderloots for making a concise, informative video to guide me through the Obsidian Digital Garden plug-in.

Behind the scenes the plug-in uses Eleventy, the static site generator I use for this website. The plug-in publishes to GitHub, Netlify kicks off a build process and then deploys the website.

This is all for free. The only thing I pay for is £10 a year my domain name.

Confirmation bias is the essential engine of AI training. The weight given to an outcome that deems it “most likely” doesn’t come from reason, but confirmation bias.

AIs with confirmation bias are also notoriously opaque - decisions are made quickly and confidently, but never justified. The closest you might get to an explanation is a vague indication that some input resembles past inputs. This is of course how prejudice and intolerance work: the only explanation is “everyone just knows this is true.”

Steve Strassmann

Mandate the publication of a standard set of APIs and events by public sector organisations. Starting with an expectation that every new service in central government departments will have an open API.

Department for Science, Innovation and Technology

What distinguishes software architecture from coding and design? Many things, including the role that architects have in defining architectural characteristics, the important aspects of the system independent of the problem domain. Many organizations describe these features of software with a variety of terms, including nonfunctional requirements, but we dislike that term because it is self-denigrating. Architects created that term to distinguish architecture characteristics from functional requirements, but naming something nonfunctional has a negative impact from a language standpoint: how can teams be convinced to pay enough attention to something “nonfunctional”? Another popular term is quality attributes, which we dislike because it implies after-the-fact quality assessment rather than design. We prefer architecture characteristics because it describes concerns critical to the success of the architecture, and therefore the system as a whole, without discounting its importance.

An architecture characteristic meets three criteria:

• Specifies a nondomain design consideration
• Influences some structural aspect of the design
• Is critical or important to application success

Source: Mark Richards and Neal Ford. Software Architecture 2024 V2 . Kindle Edition.

Neal Ford and Mark Richards