The framing that agents introduce a category of risk that requires new disciplines doesn’t hold up. The part that is new is the speed and variance. Agents have raised the profile of information security and that’s a positive. The AI governance conversation has raised the visibility of compliance for boards, for buyers, and for engineers. More care is being put into how systems handle data and how they handle delegated authority.

I’ve been working in software for over twenty years. In that time, nothing has changed my calculus on product delivery in the way that working with Claude has over the past few months. I was a sceptic for a long time. The early enthusiasm came largely from people who, in many cases, didn’t know how to develop software in the first place. None of the people I’d consider peers, or whose opinions I particularly respected, were saying anything similar.

As a programmer and a father of young children there’s not many things I hate more than “daylight saving time”. It’s the source of many software bugs, several days of unnecessary sleep disruption every year, and daylight is finite so it saves nothing. In the UK there’s been suggestion of stopping “saving” daylight, but then the question is which offset to choose for the rest of eternity. My argument is that it should be GMT (UTC+00:00), not BST (UTC+01:00).

Social cues are extremely powerful. “Dinosaurs!” is one of my favourites, because it is simple and effective. It also defeats one of my greatest nemeses: ambiguity. In a recent retrospective at Cronofy we spoke about the need for all of us to have more than a surface-level understanding of why we’re building what we’re building, and why we’re building it the way we are. We encourage people to ask questions with the likes of “if you don’t know, ask”, “there’s no stupid questions”, and similar.

The Cronofy engineering principle pretty much everyone asks me about, including non-engineers, is “no known bugs”. Common questions are around what that means in practice. This is an attempt to answer those questions in a way that I can reference, with a hope it might lead other organizations to adopt it as well. First, the specific engineering principle in full: No known bugs To maintain speed we fix bugs as they are found, and prevent their return through automated tests.

I believe one of the key skills you need to master as a leader is repetition. Repeat something often enough you are deathly bored by it, and you might have said it just enough. But you shouldn’t just repeat any old thing. You need to curate what deserves repetition. There’s a rich vein in repeating the obvious. What’s obvious to one person may not be obvious to another. A second rich vein is in initiatives.

Simple scorecards are more effective, and can provide stronger data for better insight, than the goto sliding scale. Rather than defaulting to an overall “marks out of 10” and then agonising over whether something is a 7 or an 8, building out a simple scorecard with ideally binary “yes or no” questions will produce better outcomes. Why score at all? Let’s take a step back and ask why we’re scoring at all.

Skipping straight to the point, here’s the agenda: How are you? Life is full of peaks and troughs. Where are you at right now, and what’s the trajectory? Anything you want to brag about? Professional or personal! What’s one thing we could change about work for you that would improve your life? What have you been putting off? What is concerning you? Are you fulfilled by your work? Are you getting the support you need?

The saying goes “smart people ask dumb questions” and whilst memorable it doesn’t explain “why” or provide a mental model for how to choose the kind of questions to ask. Smart people don’t ask dumb questions, they seek to eliminate ambiguity. That can be confirming an assumption of theirs is valid, or asking the speaker to explain a leap that they’ve made which everyone should understand. For example, during a conversation they’ll identify a leap between two topics and not see where the bridge is between them.

In Q1 2021 I set the goal of increasing the deployment velocity of the Cronofy engineering team. We were already deploying several times per week, often multiple times per day putting us in the top percentile of teams, but I felt we could do better to delivery value more consistently to the business. A lot had changed in 2020, we’d shifted from two production instances (US, Germany) to five (adding Australia, Singapore, UK) and we were adding a sixth (Canada) during Q1.

In late 2018 we were looking at overhauling our infrastructure at Cronofy. We had some key pain points, mostly a lack of autoscaling on the compute side, but also an eye on some future challenges. We knew auditors were about to become a key stakeholder of the system. It also felt inevitable that we would be introducing additional services to the platform. I like to think on longer term horizons. Overhauling our infrastructure was going to a significant undertaking, in both monetary and time terms.

As a leader, particularly as an early stage founder, your role is to empower people to do their jobs to the best of their ability. One of the places this is most extreme is in understanding the ebb and flow of your production environments. As a founder, you’ve seen literally everything that has happened since day one. You’ve put in place mitigations for countless edge cases and exotic failures. Your system is observable through whatever tools you had to hand.

Cronofy is ISO27001 certified and SOC2 Type 2 accredited. Though we have always been serious about how we handle data, in 2019 we set about proving that was the case. Initially, I led that effort for the SOC2 Type 1 audit in Q4 2019, before we hired Karl Bagci as head of operations who steered us through SOC2 Type 2, and ISO 27001 in Q1 and Q2 of 2020. One of my main concerns entering this process was avoiding it slowing us down as much as possible.

Quick post to help anyone else stuck in the same situation I was today. The internet, or at least my Googlefu, failed me. Today we had a Kubernetes deployment get stuck, all health checks seemed healthy, but a deployment got stuck somewhere between demoting the current replica set to be the old one, and creating a new one. This seemed to put all replica set creation in limbo as other deployments also ended up stuck in a similar state.

Over the past 4 months Cronofy has graduated from the Microsoft Ventures London Accelerator and soon after we became part of the Seedcamp family which involved an on-boarding process. Though different, the two of them covered similar ground and did similar exercises. And I saw the same opportunities being missed in both. The problem comes from good intentions, namely to spend more time working on the product. That intention means that the techies would take any opportunity to not attend the sessions laid on by the accelerator so that they could do some “real work”.

When hiring people, beyond the basic competency requirement of the role, I look for an alignment in future goals. This is why the question of “where do you see yourself in N years time?” is so ubiquitous. Any existing competencies for the role on offer are only a single part of the hiring story. Anyone who is hiring should have in mind what role they would like that person to grow in to.

As you may know Ruby 2.0.0 has been released. Despite the major version it is mostly an incremental release. However, it does include a few breaking changes so a major version is warranted. However, whilst the usefulness of most of the new features was obvious to me, I couldn’t say the same of Module#prepend. However, whilst listening to the Ruby Rogues podcast on Ruby 2 one of the Rogues (I think it was Josh Susser) referred to memoization as a case where it would make a difference.

If there was one thing that I learnt in 2012 that I would want to convey to all the developers I know, it would be this: Logging is about so much more than failures I don’t know if it was just my experience but little to no emphasis was put on logging aside from handling exceptions. In the .NET world this boiled down to adding ELMAH to your project and then forgetting about it, with Rails it meant having nothing but the logs that you got out of the box.

Usually – almost always – there’s a much simpler solution waiting to be discovered, one that doesn’t involve all the architectural noise, convolutions of the straightforward, and misguided emphasis on hooks and options for all kinds of tangents which might be useful someday. Discovering that solution may not be easy, but it is time well spent. James Hague - Minimalism in an Age of Tremendous Hardware
[read more]

My friend Dom Finn wrote a post To Fix Or Not To Fix. This is something I’ve thought about quite a lot as, lets be honest, everyone is maintaining a legacy codebase to some degree. The Boy Scout (or Girl Guide) Rule is to leave the campsite tidier than you found it. This helps avoid making the problem any worse and the propagation of Broken Windows. What motivates refactoring? The question Dom raised is how much is too much and when should you refactor?

Among some of the more interesting feedback were some requests for some links and an overview of the things mentioned in my talk. Slides I’ve put them up on Slideshare though without the context of the talk they might not be much use. I used the Bangers font from Google web fonts and the tech light palette from colourlovers. Talking points Standards I made the point that standards are important for putting the focus on the logic of the code rather than its layout.

Also, versioning APIs sucks. It’s not that it’s hard, it’s that once you publish an API, you pretty much have to support it forever. This is especially true when your API is being consumed through multiple layers. I can’t force game developers to upgrade, because they can’t force their users to upgrade. The lesson here is simple, if you don’t have to make something public, don’t! Karl Seguin - What I Learned Building Mogade
[read more]

Last Monday I gave my talk “Gain Trust and Create Change” for the first time at the London .NET user group. The guys at Skills Matter recorded the whole thing so you can watch it online if you missed it. I am reasonably pleased with how the presentation went. Watching it back was an uncomfortable experience but is very useful to feed into the next time I give this talk. Speaking of which, if you run a user group and would like me to give this talk get in touch.

An interesting article exploring the relationship between quantum physics and continuous delivery. None of it is real until it is in the hands of actual users. I don’t mean someone who will poke at it a bit or evaluate it. And I don’t mean a proxy who will tell you if the users might like it. I mean someone who will use it for its intended purpose as part of their normal routine.

I tweeted yesterday (25th Jan 2012) to ask if anyone knew of a solution as convenient as Heroku but based in the UK or Europe. The reason I asked was at Zopa we are thinking of migrating our front-end over to a Ruby stack and Heroku was the obvious option for hosting such a solution. However, as 95% or more of our traffic comes from the UK it doesn’t make complete sense to host our website outside of the UK or Europe at worst.

Yesterday, I gave a presentation on Backbone.js at the inaugural DDD North. My thanks go out to Andrew Westgarth and his team for organising it, it was a great event. I was a bit nervous as it was my first time speaking at a conference and I think it showed. I rattled through my presentation at break-neck speed, unfortunately finishing well under my allocated hour. Niall Merrigan gave me some tips for sorting that out so I’ll hopefully be more composed next time!

I came across Finagle a few weeks ago, it’s: … a protocol-agnostic, asynchronous RPC system for the JVM that makes it easy to build robust clients and servers in Java, Scala, or any JVM-hosted language. And they’ve now written a blog post announcing it to the world. I had a skim over it before but it looks like they’ve added to the documentation since then. I’ve been looking for a framework for writing servers in Scala, the Play framework is on my radar for web applications, and this looks like a great contender.

I remember watching one of the original presentations on this architecture a few months ago (no idea why I didn’t link to it at the time) and Martin’s article puts it into a format that’s easier to consume at your leisure. A really interesting approach!
[read more]

I cannot stress how much I agree with this. I’ve come to exactly the same conclusions as Zach in the last year myself. I wish I had written this post myself! Here are my highlights: Documentation is the best way to communicate your thoughts to yourself. Forcing myself first to consider the API, the interface, and the end result led to a clarity that inspired less code and a more impactful project.

There’s a whole school of thought that quantity of features is directly proportional to what you can charge for software. While clearly this is true in practice, that doesn’t mean that it’s not incredibly stupid. Every new feature makes your software more complex to use. Jesse Emery - How to keep your software awesome
[read more]

The Guardian produced a interesting series of blog posts on how they use tags to categorise their content, display related articles and so forth: Part 1 Part 2 Part 3
[read more]

Web services are a crucial part of most solutions nowadays, I spend a significant portion of my time designing and writing them and I have read a lot about them to make them better, faster and more resilient each time. This is a summary of how I approach web service design and the things I bear in mind. Protocols and content types Unless you require extreme performance from your service then use the most compatible technologies available.

I was working on a personal project over the Christmas period and wanted to make cross-site requests from an AJAX client to an API. As the client and the API were hosted on different domains they violated the same origin policy implemented by almost all browsers. Modern browsers allow cross-site AJAX requests if the API allows cross-origin resource sharing (CORS). The resources I found at the time on this were a little bare on details but I managed to piece it together and get something working.

There’s been a lot of talk in the .NET community about Sinatra clones, namely Nancy and Nina in recent times but there are several others as well. Unfortunately, all these frameworks are missing the underlying reason that Sinatra is awesome and that is Rack. Sinatra packs a hell of a lot of functionality yet weighs in at 1198 lines of code including documentation. The main reason for that is the fact it is building on top of Rack which has allowed the authors to concentrate on creating a framework without having to worry about the details of dealing with server requests.

This is in some respects a follow up to my previous post in that it has been triggered by our internal project in Ruby. When working in Ruby I consciously lean towards integration tests. Sinatra and Sequel make this really easy as using rack-test and running against an in-memory SQLite database it is easy to simulate a full conversation of HTTP requests and they run reasonably quickly too. How does this relate to learning a new language?

We are doing an experiment in using Ruby for an internal project at work. I am the most experienced in Ruby so I’m leading the choices of gems and so forth and the team questioning those choices has lead to a bit of a personal epiphany. I know that for a long while I have preferred simple tools and components. Simple tools tend to be more enabling as they give you control over precisely what is happening in your application whilst managing the boilerplate code for you.

Very interesting article on a reduction in contribution to open source and the possibly underlying forces behind it. I recently heard that RMS is pissed at cloud service companies because they are causing the decline of open source. I do have to say I agree with him that there’s a decline in open source, but I’m going to lay out a completely different reason why. This is based on my experience as being classified a “Long Beard” during an era where consumer internet shifted and the front-end became king.

Twitter has made numerous changes to fix its API. Those experiences have taught providers what mistakes not to make when launching a service. But there is still a lot for providers to learn. Alex Williams - 10 Common Mistakes Made by API Providers
[read more]

Your end users are Product People. You need to toss out this stupid idea that making something usable by DHH fanbois means you’re not HARD CORE. You can still be hard core and make something they can use, hell something any programmer can use. By doing this you will reduce costs for the people who use your software which is what that kind of software is good at. The shift in thinking is to focus on usability as if it ware a linguistic concern rather than a graphical concern.

Something I’ve seen at various times is: if (enumerable.Count() > 0) { ... do stuff ... } I’ve always preferred using: if (enumerable.Any()) { ... do stuff ... } Mostly because it reads better, but partly because I felt it was bound to be more efficient. I’m not sure if I actually confirmed that before but after seeing one today I checked on it. This is the implementation of Count():

Great article by Davy Brion which echoes the feelings I’ve been having around .NET for a while: They (Microsoft) provide architectural and design guidance for everything from your database to your business layer to your service layer all the way to your presentation layer. Unfortunately, a lot of that guidance is of a terribly low quality. Follow their guidance and odds are pretty high that either your database implementation details are leaking through all the way to your screens, or that a lot of your business details are taken care of in the database.

I’ve been on a refactoring mission for what feels like an eternity. The motivation for which is to pay off a significant portion of our technical debt. However, throughout the whole process I keep being reminded of how I believe systems should be written. Namely, simple parts brought together simply. The problem is that this normally stops at the code level. So while you’re happily abiding by the SOLID principles, your creating a massive code base with little overall cohesion.

Often when explaining something it’s easy to straight to the end goal saying: “This is how to do it. Isn’t it awesome?!” At this point you will get a blank stare and quite possibly a “why?” This can be frustrating, you’re showing something that’s an order of magnitude better than the current solution but they can’t see it. This isn’t their problem. They aren’t idiots. It’s your fault. In order to understand a solution you have to understand each step that was taken in order to reach it.

I’ve been questioning my own practices recently, seeing if there were places that I could improve, both in quality and productivity. Part of this process involved an evaluation of my test-driven approach (TDD) to developing software. I have gained and learnt so much by practicing TDD. I believe there is no better way to instil the SOLID principle within both yourself and your code than to practice TDD. Violate any of the principles and you feel the pain in your tests, they will either become monolithic and hard to write or continuously break.

Behavior-Driven Development (BDD) is a higher level of unit testing, it creates better documentation of your system by recording its intent which makes your system easier to learn for new developers and relearn for when you revisit your code further down the line. I’m going to show you how to build your own BDD testing framework on top of a vanilla unit testing framework. For my example I’m going to use NUnit but I’ve applied the same principles with MbUnit, xUnit, and it should work with any other unit testing framework too.

Though most the original links from this post are now dead, this records the time I met Adam, my co-founder and CEO of Cronofy so I’m keeping it for posterity! So I went to Nott Tuesday for the first time last month and really enjoyed it. Adam Bird, the guy who started it up seemed keen to move towards group discussion rather than one or two people presenting to the group.

One of the biggest things I took from the Progressive .NET tutorials was the idea of establishing a set of values for your team. This was raised in David Laribee’s session Towards A New Architect where he asked whose team had a set of common values. In a room of 30 or so people, I think 3 or 4 raised their hand. As soon as it was mentioned it made sense to me.

Ok, a silly one but I’ve got to share this. When walking to the hotel on Sunday before Progressive .NET I saw this in the middle of the pavement: I’m guessing someone broke the build and this is what happened to their monitor!
[read more]