Tech Talks & Conference Excerpts

[Conference talk excerpt — on microservices vs. monolith. PyCon-style talk.]
Speaker: "...so let me challenge the conventional wisdom here. We've all heard 'start with a monolith, extract microservices later.' And I mostly agree — but the phrase hides a trap.
The trap is this: when people say 'monolith', they mean different things. There's the well-structured modular monolith, where your code is organised into clearly bounded modules that happen to deploy together. And then there's the big ball of mud — everything coupled to everything, deployment is terrifying, nobody knows what anything does.
The second one is not a stepping stone to microservices. It's a dead end. You can't extract services from a codebase where nothing has clear ownership. You end up doing two hard things at once: decomposing the domain AND building a distributed system.
My recommendation: if you're starting fresh, invest in the modular monolith. Define your domain boundaries like you would for services — just don't make them services yet. Then, when you have genuine scaling or team autonomy reasons to extract, you can do it surgically, because the seams are already there."

[Conference talk excerpt — on technical debt. QCon-style talk.]
Speaker: "Technical debt is one of those terms everyone uses and nobody defines. Let me give you a framework from Ward Cunningham, who coined the term. His original metaphor was financial debt — not because it's bad, but because it has interest.
If you take on debt deliberately — you ship something quick to hit a deadline, knowing you'll refactor later — that's like a mortgage. You get the house now, you pay it off over time. Manageable.
The dangerous one is the debt you don't know you have. The codebase that grew without clear ownership, the API designed by someone who left three years ago, the 'we'll document it later' that never happened. That's high-interest debt — compounding daily.
The indicator I use: watch your onboarding time. If it takes a new developer more than two weeks to make a meaningful change, something is wrong with your codebase. That's the interest you're paying. Not in code, but in understanding tax — every new engineer has to re-discover the same knowledge the previous one discovered."

[Conference talk excerpt — on machine learning in production. MLOps talk.]
Speaker: "...there's a well-known joke in ML: getting 90% accuracy on your validation set takes an afternoon. Getting to 95% takes a week. Getting to 99% takes a PhD. But that's a distraction. Because getting your 90%-accurate model into production, keeping it there, and knowing when it degrades — that's the hard part nobody teaches.
Let me talk about model drift. Your model is trained on historical data. The world changes. Users change their behaviour. Distribution shift happens — the data your model sees in production starts to differ from the data it was trained on. And your accuracy quietly degrades with no error messages, no exceptions, no 500s. Just wrong predictions, silently, at scale.
The solution is monitoring. Not infrastructure monitoring — model monitoring. You track: prediction distribution (is the output distribution still what you expect?), feature distribution (is the input data still within training distribution?), and ground truth latency (how long before you can verify if the prediction was right?).
The phrase I use with my teams: treat your model like a system, not like a file. A file doesn't need monitoring. A system does."

[Conference talk excerpt — on API design. APIWorld talk.]
Speaker: "...let me talk about the two hardest problems in API design: backwards compatibility and versioning — which are related but not the same.
Backwards compatibility means: if I change my API, existing clients continue to work without modifications. The rule of thumb: additions are safe, removals are breaking, modifications require care.
Adding a new optional field? Safe — existing clients ignore it. Removing a required field? Breaking — every client that reads it breaks. Renaming a field? Breaking, even if you add the old name as an alias.
Now versioning. Everyone thinks versioning solves backwards compatibility. It doesn't — it just pushes the problem to 'how do you run v1 and v2 in parallel indefinitely?' URL versioning (v1, v2 in the path) is the most visible approach but it multiplies your maintenance burden. Header versioning is cleaner but harder to discover. My recommendation: invest heavily in backwards compatibility so you rarely need to version. When you do, deprecate explicitly — set a sunset header, communicate a timeline, and actually remove old versions. Zombie APIs — versions you support but nobody officially should use — are a maintenance trap."