How I plan conference travel like a software experiment

I’m heading to Malmö, Sweden soon to give a keynote. Travel planning might sound like the opposite of testing in DevOps, but I’ve found it’s a great place to practise the same habits I use with teams.

My framework, Q.E.D., Question, Evidence, Develop, is designed for making better decisions about quality. But it works just as well when the quality you care about is a stress-free journey and arriving in one piece.

Step 1: Question – Define the problem worth solving

If I frame my problem as simply “I need to get to Malmö”, I leave myself open to all sorts of vague or sub-optimal outcomes. Do I want the cheapest flight, the fastest route, or the least stressful experience?

For this trip, my real problem is: I need to travel from York to Malmö in a way that balances cost, reliability, and minimal stress, while fitting the conference organiser’s budget and my family’s calendar.

That’s a proper problem statement. It makes trade-offs visible and recognises that more than one stakeholder is affected.

Step 2: Evidence – Identify the signals that matter

In software, this is where we design metrics. For travel, my “metrics” include:

• Cost: ticket price plus hidden extras
  
• Reliability: on-time arrival rate, ease of connections
  
• Travel time: door-to-door, not just flight hours
  
• Stress factor: how much rushing, queuing, or uncertainty is involved
  

These aren’t abstract ideas, they’re the data points that determine whether I walk into the keynote fresh or frazzled.

Step 3: Develop – Decide based on evidence

In DevOps, this step is about running small experiments and then deciding to scale, pivot, or abandon. For travel, I already have historical evidence.

I’ve flown Ryanair before. The delays, the scramble for seats, and the endless add-ons made it a poor trade-off, even when the headline ticket was cheaper. That’s my “abandon” signal. There’s no need to re-test what I already know.

Instead, I pivot to a different option. Norwegian Air has been consistently more reliable for me, and their direct routes to Scandinavia cut out the pain of awkward connections. It might not be the absolute cheapest, but the evidence suggests it gives me a smoother, more predictable outcome.

The bigger takeaway

This little story isn’t really about flights. It’s about how we make decisions. Too often in software, we keep trying things we already know don’t work, or we frame the problem so vaguely that anything looks like a solution.

Q.E.D. gives me a discipline to:

• Frame the real problem, not the superficial one
  
• Choose signals that tell me whether I’m making progress
  
• Act on the evidence, even if it means abandoning a tempting shortcut
  

And whether I’m choosing a flight to Malmö or helping a team cut rework in their sprint planning, the same principles apply.

Closing thought

Quality isn’t an abstract virtue. It’s the result of many small, evidence-based choices.

So next time you’re faced with a decision, big or small, try running it through Q.E.D. You might just find yourself arriving calmer, clearer, and better prepared, for your conference or your next release.

Photo by Thijs Zijlstra on Unsplash 

The post How I plan conference travel like a software experiment appeared first on Kato Coaching.