The Problem

For over a decade, developers were told to move fast and break things. Platforms rot, morale fades, and design is dismissed as waste. It’s time to revisit an era when architecture mattered.

Something’s Wrong

SHIVERS: Something’s wrong. You feel it. It’s not the pager. Not the incident alert. It’s something worse. The quiet certainty that humans were not meant to live like this.

VISUAL CALCULUS: Suddenly, on your second monitor, a dashboard blinks like a dying eye. 3:00 a.m. Requests are timing out, quietly, rhythmically, like waves pulling bodies into the sea. Follow the traces. Oh no. A cascading failure across dozens of microservices. The last operator saw this too. They couldn’t find the root cause. This is going to be a long night.

SSH INTO PRODUCTION…

$ ssh prod-box-initech
Welcome to INITECH PRODUCTION NODE
(Asset ID: ITX-741B · Configured by SysAdmin #7)

REMINDERS:
 ▸ TPS reports MUST include a cover sheet. No exceptions.
 ▸ All employees MUST use AI. TPS reports MUST include daily AI usage logs.
 ▸ Personal scripts in `/usr/local/bin` require IT approval.
 ▸ Remember your ABCs: A = always! B = be! C = coding!

TIP OF THE WEEK:
Ask yourself, "What can YOU do for the company?"

Agility is our strength.

Last login: Sun May 19 03:19:42 2025 from 10.0.1.84

LOGIC: SSHing into production is so wrong. You know this. But you inherited the obligation. Help it, quickly! The system does things. Useful things. No one remembers why it does them that way. The intent has faded. All that remains is code. You don’t even know who the users are anymore. Do we still have users? We must… there haven’t been layoffs in a while. Keep investigating.

HORRIFIC NECKTIE: It’s laughing at you! Bratan, unplug it! Walk out the door and never look back!

CONCEPTUALIZATION: Maybe, long ago, someone meant for the system to be simple. An elegant pipeline. A clean architecture. A single diagram that explained everything. But then everyone started sprinting. And after that came the flood. Hundreds of thousands of lines of async spaghetti, poured into prod by people long gone. “We don’t have time to design”, they said. “We’ll refactor later”, they said.

HORRIFIC NECKTIE: Who is they?! THEY IS EVERYONE, Bratan! They is Scrum! They’ve been sprinting and never once asked where they’re going! Bratan, close your eyes and sprint with them! Feel the wind blow back your hair! Don’t stop until we ascend!

INLAND EMPIRE: You fidget with your tie and press your cheek to the monitor. It’s warm. You hear a voice. Muffled. From within. It says: “We were pure once. We had design reviews.”

The Voice From Within

VOLITION: The calendar invite titled “Root Cause Analysis Review” at 9:00 a.m. taunts you. Time passes, dashboards blink. You join the meeting. The haunted eyes of the last remaining staff engineer who’s seen every major incident look back at you. You’re here now. But somewhere beneath the fatigue and coffee stained tie, a thought persists.

CONCEPTUALIZATION: There must be a better way. A system that explains itself. That remembers its decisions. That makes intent durable, not disposable. What you want is reflectivity, the ability for a system to know what it’s done, and why.

RHETORIC: That’s what this series is about. A design discipline. A mindset. A refusal to let complexity win by default. You’ll learn how to trace causality through events. Preserve business intent in code. Architect systems you can reason about, so you spend more time building and less time producing RCAs.

SUGGESTION: Stick with it. Especially when it gets uncomfortable. Especially when the voice in your head says, “but this is how we’ve always done it.” That’s how you ended up SSHing into prod at 3:00 a.m.

HORRIFIC NECKTIE: Systems that explain themselves! So crazy, we must stay, Bratan! Let’s talk to the systems and hear them TALK BACK!

DRAMA: You’ve seen what happens when you don’t. Systems decay. People burn out. And eventually… always… the pager rings again. But next time, it doesn’t have to be ringing for you.

AUTHORITY: Let’s begin.

Knowledge Work Without the Knowledge

The “shift left” approach is now standard testing terminology: perform testing activities earlier in the software development lifecycle to catch defects sooner, while still continuing testing later in delivery.1

But the insight wasn’t new.

As far back as 2002, a NIST study found that software defects caught during the design phase were up to 100 times cheaper to fix than those discovered after release.2 That statistic became a rallying cry for early testing advocates, but it also highlighted that we had forgotten the value of thinking early and designing well, and this deprioritization of planning and design was accelerating.

Even the much-maligned “waterfall” model, formalized in a 1970 paper by Winston Royce, was originally a call for careful design and verification.3 Royce’s model was misunderstood and over-applied, but the underlying goal was to catch issues early, plan intentionally, and reduce downstream surprises.

So while the tools and languages have changed, the goal has always been to build software that is understandable, testable, and resilient before it becomes someone else’s problem at 3am.

And that’s what brings us here. The irony is that what we now call “shift left”, the practice of thinking early, designing intentionally, reviewing collaboratively, and pushing knowledge across the organization, used to be the default. Before agile, this was just how software was built. Planning and design came first because getting it wrong was expensive.


  1. GitHub Resources, What is shift-left testing? https://github.com/resources/articles/what-is-shift-left-testing ↩︎

  2. NIST, The Economic Impacts of Inadequate Infrastructure for Software Testing, Planning Report 02-3, May 2002. https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf ↩︎

  3. Winston W. Royce, “Managing the Development of Large Software Systems,” Proceedings of IEEE WESCON, 1970. https://www.praxisframework.org/files/royce1970.pdf ↩︎