Agile Software Engineering
This podcast explores how craftsmanship, architecture, engineering rigor, and organizational practices come together in modern R&D environments. Each edition refines and deepens my earlier reflections, building a coherent and evolving body of knowledge around Agile Software Engineering
Agile Software Engineering
First Principles in Software Engineering
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
In this episode of The Agile Software Engineering Deep Dive, Alessandro Guida explores what first-principles thinking means and how it can be applied to software engineering.
The episode moves from the philosophical roots of first principles into practical engineering questions about architecture, Agile, microservices, technical debt, software quality, and AI-assisted development.
The core idea is simple: before choosing methods, tools, frameworks, or fashionable solutions, we should understand what is fundamentally true about the problem, the system, and the engineering responsibility behind it.
This Podcast is an audio version of the written Agile Software Engineering newsletter. If you want to go deeper, don't forget to subscribe the newsletter too.
Welcome to the Agile Software Engineering Deep Dive, the podcast where we unpack the ideas shaping modern software engineering. My name is Alessandro Guida, and I've spent most of my career building and leading software engineering teams across several industries. Today, I want to look at an expression we hear more and more often. First principles. It sounds simple, and maybe even a little fashionable, but behind it, there is a very old and very powerful way of thinking. Before we choose a framework, an architecture, a tool, a process, or the latest productivity promise, we should first ask what is fundamentally true about the problem we are trying to solve. What must the system guarantee? What must be easy to change? What must remain reliable, secure, understandable, and economically sustainable? In this episode, I look at first principles thinking from its philosophical roots and bring it into software engineering with examples from agile, architecture, microservices, technical debt, and AI-assisted development. Because good engineering begins with clarity. And clarity begins with understanding the foundations. With that, let's dive in.
SPEAKER_02Picture this.
SPEAKER_01Oh yeah. We've all been there.
SPEAKER_02Right. And the team is debating this completely new initiative. The architecture is getting super complicated. People are arguing over which modern framework to use. The budget is tight.
SPEAKER_01The tension is high. Trevor Burrus, Jr.
SPEAKER_02Exactly. And then someone leans back, kind of steeples their fingers, and drops it. They say, guys, we need to think about this from first principles.
SPEAKER_01Aaron Ross Powell Ah, yes. The uh the ultimate intellectual trump card right now.
SPEAKER_02Aaron Ross Powell It really is. It's usually just deployed to completely shut down whatever debate is currently happening.
SPEAKER_01Aaron Powell Totally. I mean the phrase has been heavily popularized over the last few years, especially in the tech and startup space. You hear Elon Musk say it all the time.
SPEAKER_02Right.
SPEAKER_01But because it sounds so authoritative, you know, it just gets thrown around constantly in product strategy sessions and architecture reviews. And mostly it's just a dressed-up way of saying, let's ignore your idea and uh do it my way.
SPEAKER_02Aaron Powell Which is a real shame because if you actually look past the rockets and the electric cars, the actual concept of first principles thinking is, well, it's profound.
SPEAKER_01It really is.
SPEAKER_02It traces all the way back to philosophy. Like you have Plato who spent his whole life searching for these stable fundamental forms behind the chaotic, you know, constantly changing visible world.
SPEAKER_01Aaron Ross Powell Right, looking for the reality behind the shadows.
SPEAKER_02Aaron Ross Powell Exactly. And then Aristotle took that search and made it highly practical. He argued that to truly understand any system, you cannot look at the surface-level effects.
SPEAKER_01No, you have to dig deeper. Trevor Burrus Right.
SPEAKER_02You have to reason downward to its most basic causes. It's uh it's non-reducible truths, which he called the archai.
SPEAKER_01Trevor Burrus, Jr.: The rock bottom of a concept. You just strip away everything that is subject to change. Everything is just an assumption.
SPEAKER_02Yeah.
SPEAKER_01And you keep digging until you hit bedrock. And only then do you start building your logic back up.
SPEAKER_02Aaron Powell, finding that bedrock is our mission for this deep dive today. We are looking at issue number 45 of the Agile Software Engineering newsletter.
SPEAKER_01Aaron Ross Powell A really fantastic issue, by the way.
SPEAKER_02Oh, absolutely. Our goal today is to rescue the phrase first principles from being just another, you know, tech bro slogan. We want to rediscover what it actually demands of us when we sit down to build software.
SPEAKER_01Aaron Powell Because it demands a lot.
SPEAKER_02It does. And uh before we get into the weeds here, a quick friendly reminder to you listening. While we are pulling out the core insights for the audio version today, I highly recommend checking out the original newsletter.
SPEAKER_01Yeah, you really have to see it.
SPEAKER_02You do. It features the full text and some just fantastic illustrations that make these, you know, abstract concepts so much easier to visualize.
SPEAKER_01Totally. So to figure out what first principles thinking actually looks like in software engineering, we should probably start by diagnosing the exact opposite approach.
SPEAKER_02Makes sense.
SPEAKER_01Because the reality is the tech industry rarely operates on first principles. The default mode of operation is actually something called reasoning by analogy.
SPEAKER_02Aaron Powell Right. Which I mean that makes sense from an evolutionary standpoint, doesn't it?
SPEAKER_01Oh, for sure.
SPEAKER_02Like if we had to reason from the atomic level, every single time we opened a text editor, we would never ship anything. Analogy is just a cognitive shortcut.
SPEAKER_01Aaron Ross Powell Exactly. It's efficient. We look at a successful tech giant. See, they are using a specific pattern, say a massive microservices architecture, and we deduce that well, if we adopt their architecture, we'll adopt their success.
SPEAKER_02Aaron Powell Right. We substitute copying for critical thinking.
SPEAKER_01Aaron Ross Powell We do. And we rely on three main proxies to make those decisions habit, fashion, or authority.
SPEAKER_02Aaron Ross Powell Okay, break those down for me.
SPEAKER_01Aaron Powell Sure. So habit is the inertia of, you know, we've always deployed this way, it's just what we do. Fashion is the herd mentality.
SPEAKER_02Aaron Ross Powell Like every company on Hacker News is doing this.
SPEAKER_01Aaron Powell Exactly. And authority is deferring to a methodology, like saying the framework dictates this process, so we have to do it. Take something like SAFE, the scaled agile framework.
SPEAKER_02Yeah.
SPEAKER_01You see these massive enterprises adopting it, printing out the giant organizational posters, putting everyone into like release trains.
SPEAKER_02Aaron Ross Powell And they aren't doing it because they analyze their unique communication bottlenecks from first principles.
SPEAKER_01Aaron Ross Powell Not at all. They're doing it because a competitor did it, or a consultancy came in and told them it was the industry standard.
SPEAKER_02Aaron Ross Powell It really reminds me of um someone watching their highly successful, wealthy boss go out and buy a two-seater sports car.
SPEAKER_01Aaron Ross Powell Oh, that's a great analogy.
SPEAKER_02Trevor Burrus, Jr.: Right. You think I want to be successful too, so I'm going to go finance a two-seater sports car.
SPEAKER_01Trevor Burrus, Jr.: Just mimicking the behavior.
SPEAKER_02Trevor Burrus Exactly. You are copying the outward symbol of success, completely ignoring the underlying requirements of your own life.
SPEAKER_01Aaron Ross Powell Like the fact that you have to drive a family of six to soccer practice every day?
SPEAKER_02Aaron Ross Powell Exactly. So you end up with this very expensive, very fast vehicle that entirely fails to solve your actual transportation problem.
SPEAKER_01Aaron Powell The sports car is the perfect illustration of managing symbols instead of solving problems. First principles thinking demands that we just abandon the symbols.
SPEAKER_00Right.
SPEAKER_01We have to stop obsessing over whether we're doing agile right or if our DevOps maturity score is high enough. We have to look at the family of six and ask, what problem are we actually trying to solve here?
SPEAKER_02Right. What must the system guarantee under load? What data must never be compromised?
SPEAKER_01Yes.
SPEAKER_02So if we follow that logic, we kind of need to strip software engineering itself down to the studs.
SPEAKER_01Right down to the bedrock.
SPEAKER_02Yeah. If we burn away all the branded frameworks, the buzzwords, the specific programming languages, what is actually left?
SPEAKER_01Well, the newsletter defines the actual first principle of software engineering like this. Software exists to change the behavior of a system.
SPEAKER_02Okay.
SPEAKER_01Whether that system is a medical device, a global payment processor, or just a local restaurant's inventory tracker. The software alters what that system can do.
SPEAKER_02Makes sense.
SPEAKER_01And engineering is the discipline of making that behavior useful, reliable, understandable, secure, changeable, and economically sustainable.
SPEAKER_02I mean, that definitely strips away all the dogma. But I'll be honest, I know what happens when someone reads that in a corporate strategy document.
SPEAKER_01Yeah, roll their eyes.
SPEAKER_02They totally roll their eyes. It sounds like a platitude, right? Like make the software useful and reliable. It seems incredibly basic. Isn't that just obvious?
SPEAKER_01It sounds obvious, sure. But the nuance here is how that basic foundation actually forces your hand. How so? Well, if we genuinely accept that the software must be useful, not just feature complete, but practically useful for a human being, that foundational truth immediately dictates our actions.
SPEAKER_02Oh, I see.
SPEAKER_01We can't just guess what users want in a vacuum. We have to establish mechanisms for user feedback.
SPEAKER_02Right. And if we accept it must be reliable, we can't just hope the code works. We are fundamentally required to implement rigorous testing, monitoring, error handling.
SPEAKER_01Exactly. The methods become the servants to these fundamental goals rather than the masters.
SPEAKER_02That's a great way to put it.
SPEAKER_01Because when teams lose sight of that bedrock, the practices just become hollow rituals. Testing stops being about verifying reliability and it morphs into this game of, you know, hitting an arbitrary 80% coverage metric just to pass a pipeline gate.
SPEAKER_02Ugh, yes. Or security devolves into a compliance checklist completed right before launch.
SPEAKER_01Aaron Powell Right. Rather than a core property of the system's behavior. Yeah. We completely forget the underlying why and just blindly execute the what.
SPEAKER_02Okay. So since methods should be servants and not masters, let's turn this first principles lens on to two of the biggest sacred cows in the modern tech landscape.
SPEAKER_01Oh, let's do it.
SPEAKER_02I want to look closely at microservices and agile.
SPEAKER_01Two big ones.
SPEAKER_02Huge. Let's tackle microservices first, because they are so often treated as a like a moral improvement.
SPEAKER_01Oh, absolutely.
SPEAKER_02The industry narrative really implies that if you are running a monolith, you are somehow technologically backward. And microservices are the enlightened state.
SPEAKER_01Aaron Powell Right. But a first principles approach doesn't assign moral value to an architecture. It simply asks what structural problem the architecture is designed to solve.
SPEAKER_02Right.
SPEAKER_01Microservices introduce a massive amount of complexity. So the bedrock questions are: do different domains of your system genuinely need to scale at wildly different rates?
SPEAKER_02Yeah.
SPEAKER_01Do your development teams truly require the ability to deploy independently without coordinating with anyone else?
SPEAKER_02Aaron Powell And perhaps the most critical question: does your organization actually possess the operational maturity to handle distributed system complexity?
SPEAKER_01That's the kicker.
SPEAKER_02Can you handle network partitions, eventual consistency, distributed tracing, complex failure modes?
SPEAKER_01Aaron Powell Exactly. And if the answer to those questions is yes, because you know you are operating at the scale of a global streaming service, then the microservices pattern is a brilliant engineering trade-off. Sure. But if your team lacks that operational maturity and your scaling needs are modest, adopting microservices is a catastrophic error.
SPEAKER_02Aaron Ross Powell You're just making things harder for yourself.
SPEAKER_01Way harder. You take a centralized complexity that you could easily debug on a single machine and you shatter it across a network boundary.
SPEAKER_02Right. A boring, well-structured monolith handles centralized complexity beautifully.
SPEAKER_01It really does. The goal isn't to just possess a microservices architecture, the goal is to manage change and complexity efficiently.
SPEAKER_02Which brings us to agile. Another area where the practices have largely just detached from the principles.
SPEAKER_01Oh, big time.
SPEAKER_02I mean, I have been on teams where we religiously did the daily stand-up, we meticulously groomed our backlog, we held retrospectives, and we still built the wrong product at a glacial pace.
SPEAKER_01Agile theater.
SPEAKER_02Agile theater. Exactly. We resembled a cargo cult, you know, doing the rain dance, wearing the right feathers, but having absolutely no understanding of the atmospheric pressure systems that actually cause rain.
SPEAKER_01That happens because organizations mistake the mechanisms for the principles. They think the bedrock of Agile is like the two-week sprint or the user story format.
SPEAKER_00Right.
SPEAKER_01But the actual foundational truth of Agile is that software development is dominated by uncertainty. Trevor Burrus, Jr.
SPEAKER_02Just massive uncertainty.
SPEAKER_01Exactly.
SPEAKER_02We simply do not know what we do not know on day one. User requirements will shift, the market will change, and the technology will present constraints we just didn't anticipate.
SPEAKER_01And because uncertainty is the overriding reality, your engineering process must optimize for discovery and adaptation. You need short feedback loops to validate your assumptions. Right. When you view agile through the lens of managing uncertainty, the specific ceremonies suddenly make sense as tools rather than rules.
SPEAKER_02Oh, that's a key shift.
SPEAKER_01We don't do iterations to micromanage developers. We do iterations to force a feedback loop. We don't build cross-functional teams because it looks nice on an organizational chart. We do it because handing off work between isolated siloed teams destroys context.
SPEAKER_02Aaron Powell Yeah. Handing a spec document from a design team to a front-end team and then to a back-end team. I mean, it's essentially playing a corporate game of telephone.
SPEAKER_01Yes.
SPEAKER_02Every boundary crossed is a loss of learning. And it's a delay in discovering if the original idea actually even worked.
SPEAKER_01Aaron Powell Exactly. So if you were hitting every sprint goal perfectly and delivering exactly what was planned six months ago, but you are failing to adapt to new information.
SPEAKER_02We weren't actually agile.
SPEAKER_01You were doing the rain dance while ignoring the sky.
SPEAKER_02I love that. Okay, so if agile processes are how we handle the uncertainty of the future, we have to talk about how we handle the baggage of the past.
SPEAKER_01The memory of software.
SPEAKER_02Right. Software is incredibly stubborn, which brings us to architecture and technical debt. A really common trap is viewing software architects as this like ivory tower central committee where their primary job is drawing UML diagrams and just saying no to developers who want to try new things.
SPEAKER_01Which entirely misses the function of architecture. From first principles, architecture is the set of technical decisions that shape the future cost of change.
SPEAKER_02The future cost of change.
SPEAKER_01Yes. Good architecture acts as a shield for agility. Bad architecture is an anchor.
SPEAKER_00Right.
SPEAKER_01Because code has memory. Every dependency you introduce, every tight coupling you create, leaves a trace. It becomes a tax levied on any future feature you want to add.
SPEAKER_02The newsletter draws a really sharp distinction here between team autonomy and team independence. And I think it's vital we unpack that because we hear constantly that teams must be autonomous to move fast.
SPEAKER_01Right. Autonomy is essential for local decision making, like how a team organizes its internal work or how it implements a specific feature. Sure. But granting teams total independence is a completely different story. If team A chooses one tech stack and data standard and team B chooses a completely different one, they might move very fast individually for a few months.
SPEAKER_02But they are generating massive integration debt for the organization.
SPEAKER_01Massive. Large, complex systems require alignment around shared constraints.
SPEAKER_02Aaron Powell If you lack that shared architectural discipline, you get the illusion of speed locally, but you create an unmanageable, tangled mess globally when those systems inevitably need to talk to each other.
SPEAKER_01Aaron Powell Which is the perfect entry point to understand technical debt. People often colloquially use tech debt to mean lazy code or bugs.
SPEAKER_02Right, just bad code.
SPEAKER_01But it's actually an economic reality. Technical debt is the accumulation of interest on technical decisions that optimize for the short term at the expense of the long term.
SPEAKER_02It's the duplicated logic, the missing test coverage.
SPEAKER_01The outdated library that literally no one wants to touch.
SPEAKER_02Yeah.
SPEAKER_01And eventually, product managers start asking why feature delivery has slowed to a crawl. They assume the team is just unmotivated.
SPEAKER_02But the root cause is structural. The system itself has made speed prohibitively expensive. Let me pose a scenario though. Is taking on technical debt ever actually a good engineering decision?
SPEAKER_01Think about it exactly like financial debt. If a startup takes out a loan to build a factory, that is a rational, deliberate choice. They are leveraging debt to capture a market window, knowing full well they have to pay interest. In software, a team might deliberately take a shortcut, maybe hard-coding a configuration instead of building a dynamic admin panel, because hitting a specific launch date is critical for the company's survival.
SPEAKER_02So that can actually be brilliant pragmatic engineering.
SPEAKER_01Yes. But the distinction is whether the debt is visible or hidden.
SPEAKER_02Oh, that's important.
SPEAKER_01The startup leveraging alone has a ledger. They know exactly what they owe. Visible tech debt is tracked, understood, and managed.
SPEAKER_02Right. Whereas hidden tech debt is like a legacy enterprise maxing out five credit cards because they refuse to align on shared constraints and they just accept the chaos as the way things are.
SPEAKER_01Exactly. Hidden debt is what slowly kills legacy systems. Visible debt is a strategic tool.
SPEAKER_02Okay, let's take this entire first principles framework we've built separating the bedrock truth from the mechanism, and let's apply it to the most hyped, chaotic topic of this decade.
SPEAKER_01AI coding tools.
SPEAKER_02AI coding tools. The headlines tell us daily that AI is going to replace developers and automate software engineering out of existence.
SPEAKER_01Applying intellectual hygiene here is critical, otherwise, we just get swept away by the marketing. Right. The core flaw in the current AI discourse is the assumption that software engineering is simply the mechanical act of producing text that compiles into code.
SPEAKER_02Yeah, the conversation is all centered around how many lines of boilerplate can the LLM generate per minute?
SPEAKER_01Which is entirely the wrong metric. We established our first principle earlier. The purpose of engineering is to create useful, reliable, secure, and changeable behavior in a system.
SPEAKER_02Yes.
SPEAKER_01Large language models can absolutely accelerate the typing part of that process. They can scaffold a project, suggest test cases, or help refactor a tricky function. But an AI does not assume the responsibility for the correctness of that code in the real world.
SPEAKER_02This highlights what I think is the most crucial realization about AI in our industry right now. It's the asymmetry of effort.
SPEAKER_01Tell me more.
SPEAKER_02Well, the cost to generate a thousand lines of code is approaching zero. But the cognitive load required to read, verify, debug, and maintain those thousand lines of code remains completely unchanged.
SPEAKER_01Oh, that is spot on. The bottleneck of software engineering hasn't disappeared. It has just shifted.
SPEAKER_02Right.
SPEAKER_01It has moved from code generation to code verification. After the AI spits the text onto the screen, a human engineer still has to understand how it integrates with a legacy database.
SPEAKER_02They have to ensure it doesn't introduce a novel security vulnerability.
SPEAKER_01And verify that it actually solves the nuanced domain problem the user asked for.
SPEAKER_02So if you have a broken, highly confused engineering process and you integrate an incredibly fast AI generation tool into it, you aren't fixing the process. No. Automating confusion just allows that confusion to travel at light speed. Wow. Right. You haven't solved your underlying architectural problems, you've just accelerated the rate at which you can produce technical debt.
SPEAKER_01And that points to exactly why we have to be so vigilant against false principles.
SPEAKER_02False principles.
SPEAKER_01Yeah, hidden assumptions that masquerade as foundational truths. Like an organization might operate on the assumption that velocity is inherently good or shipping more features creates more value, or AI code is cheaper.
SPEAKER_02Aaron Powell But I mean, velocity is only an advantage if your compass is calibrated. If you are driving 100 miles an hour toward a cliff, velocity is your enemy. Exactly. And more features only equal more value if they actually remove friction for the user. If they don't, they are just permanent maintenance liabilities sitting in your code base.
SPEAKER_01First principles thinking acts as a filter against those false assumptions. It forces us to demand proof from our metrics and our tools.
SPEAKER_02Bringing all of this together, engineering, is fundamentally an endless tug of war.
SPEAKER_01It really is.
SPEAKER_02On one side of the rope, you have the drive for creativity, exploration, and the need to move fast to capture value. And on the other side, you have the absolute necessity of reliability, architectural discipline, and long-term responsibility. Reasoning from first principles doesn't mean rejecting your past experience. And it certainly doesn't mean ignoring modern tools like AI or microservices. What at all? It simply means forcing those tools to justify their existence against the bedrock truth of the problem you are solving.
SPEAKER_00Right.
SPEAKER_02And when you do that, you achieve clarity. And in a tech landscape drowning in hype, clarity is the single most valuable engineering quality you can possess.
SPEAKER_01Truly. Before you write a single line of code or adopt a single framework, you must understand what is fundamentally true about the system you are trying to change.
SPEAKER_02Well, we have covered incredible ground today, but we have genuinely only scratched the surface of the course material.
SPEAKER_01So true. There is so much more in there.
SPEAKER_02Yeah. If you want to truly master these concepts and see the visual breakdowns, you need to remember to read and subscribe to the full article from the Agile Software Engineering newsletter.
SPEAKER_01Highly recommended.
SPEAKER_02It has fantastic illustrations and honestly much more in-depth content that we simply couldn't fit into this deep dive.
SPEAKER_01Yeah, definitely check it out.
SPEAKER_02Also, a quick reminder: this deep dive is completely free, but it is a massive help to us if you press like on the platform you are listening to right now.
SPEAKER_01It really helps.
SPEAKER_02It does. Hit subscribe to receive all future issues, and please repost or forward this deep dive and the related article to your friends and colleagues. It is a great help.
SPEAKER_01As you head back to your own code bases and architecture meetings this week, I want to leave you with a different angle to mull over on your own.
SPEAKER_02Okay, let's hear it.
SPEAKER_01If first principles thinking requires us to ruthlessly strip away the frameworks, the acronyms, and the habits, ask yourself this.
SPEAKER_02Yeah.
SPEAKER_01The next time your team proposes adopting a brand new framework or tool, ask yourself what underlying complexity are we introducing right now, and exactly who is going to pay for it later?
SPEAKER_00Thank you for listening to the Agile Engineering Deep Dive Podcast. If you found this episode valuable, feel free to share it with someone who might benefit. A colleague, your team, or your network. You can access all episodes by subscribing to the podcast and find their written counterparts in the Agile Software Engineering newsletter on LinkedIn. And if you have thoughts, ideas, or stories from your own engineering journey, I'd love to hear from you. Your input helps shape what we explore next. Thanks again for tuning in. And see you in the next episode.
Podcasts we love
Check out these other fine podcasts recommended by us, not an algorithm.
Darknet Diaries
Jack Rhysider