Learning to Love DDD - A Tale of Two Products is a conference talk I started delivering in 2022. In some respects, it's a love letter to Domain Driven Design after years of building systems both with and without the practice.
Sometimes I meet software engineers who say "Just tell me what to build and let me work out how to build it."
In conversations with non-technical founders and leaders, I often come across the lament that the engineering department is an opaque box - requirements go in, working (sometimes not working) software comes out (but sometimes doesn't).
I was recently flattered to be invited to speak at the UNSW 2022 Co-Op Scholarship Induction Ceremony as an Alumni. What follows is the text of the written speech - as I don't refer to notes when speaking, what came out was slightly different but this hits the key themes.
One of the awesome things about working in a startup is that you get to take on an enormously diverse range of tasks. But how do you ensure you're delivering high quality work across all of them?
The phrase “loosely coupled” is used alongside “microservices“ so often you'd be forgiven for assuming you get loose coupling for free, just by “doing“ microservices. (Spoiler: you don't.) But what actually is coupling? How loose is loose? Should we also be worried about cohesion? And why do we care?
An exploration of the history and legacy of the 4 + 1 architectural views.
Have you ever worked on a microservices system struggling with the complex interactions of services and teams? Are you a startup hoping to build at MVP speed, but scale quickly? The 4 + 1 Views may help!
Hi, welcome to Dev Cycles. This blog is a place for me to share my experiences co-founding and helping grow two technology businesses to scale. I'm a developer at heart so it will mostly be about the tech, but it will also be about the intersection of technology, business, leadership, society and ethics.