I got into XP at BBC Sport around 2013. TDD was a required skill, but I lacked experience, so I spent my notice period reading, practising, and finding resources to understand the technique.
That led me to a fantastic talk by Ian Cooper, "TDD Where did it all go wrong"[1], where he not only recommended test-driven development as a process but also emphasised writing tests that focus on behaviour rather than implementation details.
By following this advice, I suddenly found a freedom I'd never experienced - a freedom to make changes with high confidence over time, a low-stress environment and a rapid feedback loop that meant if I broke something, I found out in seconds.
It wasn't the technology. It was the practices. The tight feedback loops. The fact that you could stop at any point and ship what you had, because the system was always in a working state. I'd never experienced that before. Once I had, I couldn't go back.
After BBC Sport, I applied that approach everywhere: at Sky, where I helped rebuild their homepage and other features; at Equal Experts on high-profile applications for a top global law firm; and at NewDay in FinTech, developing a multi-branded credit card platform for household names. The companies changed, but the practices stayed - and they worked everywhere I went.
Somewhere along the way, I ended up specialising in something most people think is impossible - TDD on the front end. I've been doing it for over a decade now. I separate styling from behaviour, develop behaviour test-first, and only test CSS when it's tied to business logic. It works. I'll happily debate anyone who says otherwise. I know it works because I've been doing it day in and day out all this time.
What this site is about
I write about software development practices - TDD, pair programming, continuous delivery, clean architecture, and domain-driven design. The stuff that actually makes a difference to whether your team can ship with confidence.
For me, it all comes back to feedback. Software development has two feedback loops that matter. The technical one - TDD gives you a signal in seconds. And the customer one - shipping real work and getting a response in days, not months. Everything I care about is in service of those two loops.
I'm not interested in velocity, story points, or utilisation metrics. I'm interested in whether the thing we built actually solves someone's problem. The rest is theatre.
I discovered these practices work brilliantly with AI.
I shared my dotfiles repo, which had a collection of rules I'd written based on these practices, and it took off in a way I didn't expect. What started as a personal CLAUDE.md file - basically me writing down how I think about software development so AI tools would follow the same practices - turned into a full system. Over 20 skills and agents, decision frameworks for everything from when to use schemas to when an abstraction is worth the complexity.
The core idea is simple. AI-assisted development without strong practices just produces more mess, faster. So I encoded 20 years of XP into something machine-readable: TDD as non-negotiable, mutation testing to verify that your tests actually catch bugs, hexagonal architecture to contain the blast radius, and domain-driven design to keep the language consistent.
People have been telling me these files are genuinely helping them. Not just as AI instructions - as a way of thinking about software development. That's what made me want to write about it properly, which is how this site started.
Lately, I've been building a micro-SaaS framework using these practices with AI, so a lot of what I write comes from that lived experience, too. What worked, what didn't, what I'm still figuring out.