Inside Dev Korea #9 with Jan de Vries: chaos monkeys, technical debt, and a packed room in Seoul

Want to feel what the night was like? From the talk to the networking and everything in between, here's a quick aftermovie of Dev Korea #9 🎥.

On June 17 we ran Dev Korea #9. More than 110 people came out for the evening. Developers, platform and infra folks, founders, a good mix from across the Seoul tech scene, all there for one long talk and the usual tail of conversations afterward.

Jan de Vries, a consultant, trainer and coach based in the Netherlands, and the founder of Antifragility.works and BlueOceanRecon.com, was in Korea for two weeks, his first time in the country, and decided to spend one of those evenings giving a talk with us. He has been doing antifragility talks at conferences in Belgium, Spain, Switzerland, Luxembourg, Czech Republic, Australia, Japan, Malaysia and Canada over the last three years. Seoul is now on that list.

He opened with a show of hands. Four people in the room were familiar with antifragility. Nobody was working in risk management. By the end of the hour it was clear why he asked both questions together.

Risk management is risk theater

Jan started with a consultancy report about coping with unknown risks. Read the actual strategies in it, he said, and almost every one is about known risks. You end up preparing for the failures you already have names for, and not for the ones you don't.

That's the case Nassim Nicholas Taleb makes when he calls risk management risk theater. His alternative is not better prediction. It's becoming less fragile to risk in the first place, and ideally benefiting from it.

Until 2012 we only had two words for something that isn't fragile: robust and resilient. Antifragile added a third. Jan walked through all four with a picture for each.

• Fragile is glass. Add stress and it breaks.
• Robust is reinforced concrete, or a presidential limo. It holds for a long time, then it breaks anyway.
• Resilient is the Phoenix. It comes back, but it comes back as the same bird. In software, that's an Airbus A380 cockpit: hydraulics fail, backups take over, it keeps flying, and it is never better than it was designed to be.
• Antifragile is the Hydra. Cut off one head and two grow back. Every attack makes it stronger.

The IT version of the Hydra is Netflix's Chaos Monkey, which kills things in production between 9am and 3pm so that engineers fix them during office hours instead of at 2am. There was a latency monkey injecting artificial delay, and another one hunting down unused cloud resources and switching them off, with a 30 minute grace period before it came back around. Netflix eventually became immune to the Chaos Monkey, so they built the Chaos Gorilla to break bigger things. The whole Simian Army is on GitHub if you want to point it at your own systems. Test environment first.

He also made a point about layers. A single aircraft is resilient. The aviation industry is antifragile, because it learns from every crash. When the 737 MAX went down in 2018 and 2019, every similar aircraft in the world was grounded until the cause was understood.

Technical debt is the most fragile thing in IT

He asked the room what the single most fragile thing in software is. The answer he was looking for was technical debt.

His graph for it is the one worth stealing. The cost of change always rises as software ages, and that's fine, that's the optimal line. Technical debt is the gap between that line and what your changes actually cost. It gets dangerous when the curve turns into a hockey stick, because past that point the software is beyond repair and your responsiveness to customers is gone. He quoted Gene Kim's definition, which is still the best one: technical debt is what you feel the next time you want to make a change.

Getting rid of it is what Taleb calls via negativa, the power of subtraction. Our instinct is to add: another process, another layer, another tool. Via negativa says remove the feature, remove the dependency, remove the layer.

The practical version he showed came from Project to Product: a four-color backlog. Green is features, red is defects, blue is paying down debt, orange is mitigating risk. Customers only ever ask for green and red. Teams that only deliver green and red watch their defect count climb forever. The teams that keep spending on blue and orange are the ones whose defect count eventually comes down. He suggested a layered kanban board as a simple way to hold yourself to that split.

He then asked the room which balance matched their own workplace. Somebody answered "a column with no green at all," which got a laugh. There's a word for that, Jan said. It's called a refactoring sprint.

Optionality, and why vendor lock-in hurts

The middle of the talk was built around three forms of asymmetry. The first was nonlinearity: anything with more upside than downside from random events is antifragile, and the reverse is fragile. The trick to spotting it is asking whether the thing accelerates toward pain or toward gain. Jan's memory aid is that the fragile curve is a frown and the antifragile curve is a smile.

Deployments per month is the classic smile. Going from zero to a few deployments hurts a bit. Keep pushing and you end up with a working CI/CD pipeline, and at that point shipping ten times a day or three times a month stops mattering. Continuous deployment is antifragile. Coordinated tasks inside a software project is the frown: coordination helps at first, then dependencies and deadlines pile up and it accelerates toward pain. Software projects are fragile.

The second was optionality. When people hear the word "options" they think financial options, which are expensive. Most of the useful options are non-financial, and cheap or free, and we just don't recognize them as options.

The clearest anti-pattern is vendor lock-in. He put an ERP strategy next to a best-of-breed strategy and worked through the criteria. Almost every advantage lands on the best-of-breed side. Even integration, which is supposed to be the ERP selling point, usually isn't as good as promised, while a standalone vendor treats integration as a knockout criterion because they don't get bought otherwise. His conclusion: ERP systems are fragilizers.

Other ways to buy yourself options, most of them cheap:

• T-shaped profiles, which give the individual more moves and give the employer cross-pollination and fewer silos
• A bus factor of at least three. A bus factor of one means one resignation ends the project
• Real redundancy. His analogy: if you always sleep on your left side you technically only need half a mattress, but that's zero redundancy, and the first thing that goes wrong ruins your night
• Observability. Monitoring covers the known unknowns. Observability is what you have for the unknown unknowns, which is exactly the territory antifragility cares about
• The barbell strategy. Put 80 to 90 percent of your resources into boring, safe, predictable work, and 10 to 20 percent into genuinely speculative bets. Avoid the middle
• Microservices, which turn one big irreversible decision into many small reversible ones. If one turns out badly you rewrite it instead of rewriting the empire

That last one comes with a line that stuck with a lot of people: software has diseconomies of scale. Milk is cheaper in bigger cartons. Software is cheaper in lots of small ones.

He also asked the room whether MTBF or MTTR is the antifragile metric. MTTR, and it isn't close. There are two cases where you optimize mean time between failures instead: hardware you launched into space, and a medical device implanted in someone's chest. Everywhere else, optimize for recovery, because antifragile systems assume failure will happen. They're supposed to break a little, all the time. That's the part that makes them stronger.

Skin in the game

The third asymmetry was fragility transfer: one party takes the downside while another takes the upside. The reverse of that is skin in the game, meaning you have something real to lose.

His example goes back 3,700 years. Hammurabi's code 229 said that if a builder builds a house and the house collapses and kills the owner, the builder is put to death. Houses in Mesopotamia got noticeably more stable after that.

Then he pointed the same lens at how we organize software work:

• Silos are fragilizers. A dev in a dev silo has no skin in the ops game and vice versa. This is the actual reason DevOps works: what I build in the morning I maintain in the afternoon.
• Projects are fragilizers. A project manager owns the delivery and the initial cost, and usually owns none of the operating cost that follows for the next twenty years.
• Command and control is a fragilizer. Information travels up to authority, a decision comes back down, and everything is slow and worse for it. The fix is to push authority down to where the information already is, which needs technical competence, organizational clarity and shared priorities to work.

He closed this section with organizational debt, which Steve Blank describes as technical debt but worse. It's what you have when your hierarchy actively works against your operational flow. And it isn't a fair fight, because Conway's law says your systems will end up mirroring your communication structure whether you like it or not. Published in 1967, still unbroken. The upside is that you can also use it deliberately: simplify the organization if you want simpler systems.

His sharpest line here was about Frederick Taylor, who published his five principles of scientific management in 1911 and died in 1915. Management decides, workers execute. If that still describes your company, you're running a 115 year old operating model built for assembly lines, on software.

Most of the reasons an organization isn't ready for digital transformation aren't technical, he said. Technically it can be solved. Organizationally it stays a problem.

Don't be a fragilista

The last slides were his advice, and it's counterintuitive on purpose.

A CI/CD engineer who suppresses every small failure to keep the pipeline green is setting up a much larger failure later. You don't want small failures hidden. You want them exposed, visible, and known to everyone. Spend your error budget. Ship the high-risk high-reward feature. Upgrade the old infrastructure. Run the disaster recovery drill.

Avoiding black swans is impossible. Building something that survives them isn't.

A full room and a long Q&A

More than 110 people stayed through the evening. Doors opened at 6:30 and the pizza and the burgers went fast during check-in, which is usually where the first round of conversations starts before anyone sits down.

The Q&A ran long, in a good way. It started during the talk and never really stopped. People asked about infrastructure as code and avoiding cloud lock-in, whether AI-assisted development creates technical debt faster than it clears it, how to make a case for antifragility inside a risk-averse company, what to read on the organizational side, and whether antifragility is worth the effort for every team or only some.

A great moment happened between two attendees. Someone asked a distributed infrastructure question Jan said was past his technical depth, and someone else in the room picked it up and answered from their own experience building anomaly detection. Jan's follow-up was whether those anomalies were made visible across the organization. They were. That's the point, he said. You should be proud of the things you found that went wrong.

And yes, someone asked him if he knew there's a K-pop song called Antifragile. He didn't, but he did know that his Google alert for the word is mostly music.

Plenty of people stuck around for the networking hour afterward anyway, food or no food.

Huge thanks

This event wouldn't have happened without:

• Jan de Vries for spending one of his two weeks in Korea giving us an hour of this, and for being honest about the parts he doesn't have answers for yet
• Cry Cheeseburger for the burgers
• The volunteers who kept the night running: Sonali, Brian, Chanwu, Oscar, and Rob
• And everyone who showed up, asked questions, answered each other's questions, and stuck around to talk

Watch the talk

The full talk is online:

• Beyond resilience: Architecting antifragile systems, by Jan de Vries

You can find every published Dev Korea talk on our talks page.