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
What Really Defines High-Quality Software?
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 the gap between engineering quality and customer-perceived quality.
While engineers often define quality in terms of architecture, testing, and process, customers evaluate it through experience: whether the software works, whether it is easy to use, whether it is reliable, and whether it performs without friction.
The episode reflects on why many essential engineering practices remain invisible when they work well, why elements like security are expected but rarely noticed, and how this disconnect can lead teams to optimize for the wrong signals.
If you are building software in complex environments, this episode offers a grounded perspective on how to align engineering discipline with what truly defines quality from the outside.
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. And today I want to talk about something that sounds simple at first, but becomes surprisingly complex the moment you look at it closely. Quality. In engineering, we spend a lot of time discussing quality. We talk about architecture, test coverage, security, performance, delivery processes, and all the practices that help us build better systems. Over time, these elements become our reference points and they shape how we evaluate whether a product is well built or not. But there is a different perspective that is easy to overlook. Because when customers think about quality, they rarely think in those terms. They are not evaluating our architecture or our test strategy or the way we organize our work. What they experience is something much more direct. Whether the software does what they need, whether it is easy to use, whether it behaves consistently, and whether it responds fast enough to stay out of their way. And that creates an interesting gap. A system can be well engineered and still feel difficult to use. It can be technically sound and still be perceived as unreliable. It can follow all the right practices and still fail to build trust with the people who depend on it. In this episode, I want to explore that gap between engineering quality and experienced quality. Why it appears, why it persists, and why some of the things we consider most important as engineers are often invisible to the people using the systems we build. We will look at how expectations like reliability, usability, performance, and even security are perceived from the outside and how we can translate those expectations into concrete engineering discipline rather than abstract principles. Because in the end, quality is not defined by how we build software, it is defined by how it is experienced. Let's dive in.
SPEAKER_02Imagine spending like two years and five million dollars building the most architecturally flawless, perfectly secure software platform on the planet.
SPEAKER_01Oh, a total masterpiece of engineering.
SPEAKER_02Right. And then your customer calls it absolute garbage because, I don't know, a single drop-down menu took half a second too long to load.
SPEAKER_01Yeah. Which happens all the time.
SPEAKER_02It really does. Welcome to this deep dive. Today we're taking on a genuinely fascinating mission for you. We are looking at issue number 29 of an agile software engineering newsletter.
SPEAKER_01Aaron Powell, which is a fantastic source, by the way.
SPEAKER_02Aaron Powell It is. And we're using it to unpack this massive and frankly completely maddening disconnect between what engineers think makes a high-quality product and what you the actual customer experience.
SPEAKER_01Aaron Powell It is a profound disconnect. And you know it it stems from a very natural human tendency. Really is. Well, professionals in any highly technical field, they tend to define their value by the complexity of their tools and the rigor of their methods. Trevor Burrus, Jr. Right. So in software engineering, quality is almost universally discussed in terms of like system architecture, test coverage, deployment pipelines, maybe security protocols. Trevor Burrus, Jr.
SPEAKER_02Okay. Let's unpack this. Because the newsletter points out a fundamental shift in perspective that kind of ruins that entire paradigm.
SPEAKER_01Aaron Powell It really does.
SPEAKER_02Engineers describe quality by how a product is built, but the customer, the person actually writing the check for the thing, has absolutely zero visibility into how it's built.
SPEAKER_01Aaron Powell None at all.
SPEAKER_02Aaron Ross Powell Right. So they define quality entirely by how it is experienced.
SPEAKER_01Aaron Powell What's fascinating here is how incredibly simple the customer's evaluation model actually is when you strip away all the technical jargon. Trevor Burrus Oh, totally. Like a user evaluating a piece of software is essentially asking a rapid-fire series of uh subconscious questions.
SPEAKER_02Aaron Ross Powell Like, does this do what I need it to do? Aaron Powell Exactly.
SPEAKER_01Is it easy to use? Is it consistent? Yeah. And you know, is it reasonably fast? Yeah. They do not care if the back end is a state-of-the-art microservices architecture or just a 20-year-old monolithic code base held together by digital duct tape.
SPEAKER_02Trevor Burrus, Jr. Right. It's like think about a chef. A chef obsessing over the exact carbon content of their imported Japanese steel knives. Trevor Burrus, Jr.
SPEAKER_01Oh, spending thousands of dollars on a blade.
SPEAKER_02Exactly. But the diner in the restaurant out front, they only care if the steak is cooked properly and actually arrives at the table hot.
SPEAKER_01The diner isn't paying for the knife.
SPEAKER_02No, they're paying for the meal. And what's wild is that the newsletter highlights how this perception of quality remains like incredibly stable across completely different industries.
SPEAKER_01Use universal.
SPEAKER_02Yeah. A nurse using really complex medical software and a teenager using a social media app, they are judging quality using the exact same metrics of friction and consistency.
SPEAKER_01Right. The context of the work changes dramatically, obviously. But the human perception of friction does not.
SPEAKER_02Yeah.
SPEAKER_01If the software solves the problem without making the user think about the software itself, it's perceived as high quality.
SPEAKER_02And if it introduces confusion, it's bad.
SPEAKER_01Simple as that. The tool itself is totally irrelevant to the experience.
SPEAKER_02Aaron Powell Wait, I have to push back on this premise just a little bit.
SPEAKER_01Okay, go for it.
SPEAKER_02If customers only evaluate that tangible surface-level experience like the meal, stick with our analogy, what happens to the incredibly vital, highly technical elements?
SPEAKER_01Like what?
SPEAKER_02Well, take security. I mean, we hear about data breaches every single day, right?
SPEAKER_00It's true do.
SPEAKER_02Isn't top-tier airtight security a massive selling point? Wouldn't a customer actively praise an app that perfectly protects their data?
SPEAKER_01You would naturally assume that. But the author makes a really brilliant distinction here regarding human psychology. Oh. Yeah. Security requires deliberate design, constant vigilance, deep technical competence from the team. So to the engineers, it is a massive feature.
SPEAKER_02It's huge.
SPEAKER_01But to the customer, security and reliability for that matter, they are assumptions. They are not features.
SPEAKER_02Assumptions, meaning the user just fundamentally expects the door to be locked when they walk away.
SPEAKER_01Exactly. Think about the plumbing in your house.
SPEAKER_02Okay.
SPEAKER_01You don't walk into your bathroom, turn on the faucet, see water come out, and start like praising the brilliant hydroengineering of the city's infrastructure.
SPEAKER_02Right. I'm not writing a thank you note to the city planner. Trevor Burrus, Jr.
SPEAKER_01You just expect the water to flow. Security operates on that exact same psychological baseline. It does not earn active recognition or gold stars when it's present.
SPEAKER_02It just sits invisibly in the background.
SPEAKER_01Yep. But the absolute millisecond, it fails. It instantly and catastrophically erodes all trust.
SPEAKER_02Aaron Powell Wow. So it's a completely thankless requirement. You never get applauded for keeping the system secure, but you will absolutely be fired the moment it's compromised.
SPEAKER_01The harsh reality. And this actually maps perfectly to formal engineering standards, even if the vocabulary is different.
SPEAKER_02How so?
SPEAKER_01The source text brings up the ISO IEC 25010 quality model.
SPEAKER_02That sounds like a mouthful.
SPEAKER_01No, it's a massive formal framework. It categorizes software quality into dimensions like functional suitability, usability, performance efficiency, and security.
SPEAKER_02Which honestly sounds incredibly dry and technical.
SPEAKER_01It is formal, yeah. But look at the substance of it. Functional suitability is literally just an engineer's way of saying, does it do what the user paid for? So the difference between the ISO model and the user's brain isn't the definition of quality, it's the emphasis. Engineers emphasize the complex construction of the security.
SPEAKER_02And customers just emphasize the invisible assumption of it.
SPEAKER_01Exactly.
SPEAKER_02Here's where it gets really interesting, though.
SPEAKER_01Okay.
SPEAKER_02Because if the complex tools don't earn praise and foundational pillars like security are just invisible baseline assumptions, what about the actual day-to-day processes?
SPEAKER_01The way teams work.
SPEAKER_02Right. I'm talking to agile, entire tech empires are built on agile frameworks, scrum masters, camban boards, you know, two-week sprints.
SPEAKER_01Oh, yeah, a massive industry.
SPEAKER_02Are you telling me that a million-dollar agile transformation is completely invisible to the user? Like, does a flawless engineering process guarantee a quality experience?
SPEAKER_01It absolutely does not.
SPEAKER_02Wow.
SPEAKER_01The trap here is that engineers naturally gravitate toward what they can control.
SPEAKER_02Which makes sense.
SPEAKER_01Right. They can control their daily stand-up meetings, they can control their sprint backlogs, they can tightly control their code repositories, but the customer does not experience your process. The customer only experiences the consequences of your process.
SPEAKER_02I see. So you could have a beautifully organized sprint, perfect code reviews, maybe an elegant architecture.
SPEAKER_01Yep.
SPEAKER_02But if the system crashes when a thousand people log in simultaneously to buy concert tickets, the user considers your software to be total garbage.
SPEAKER_01100%. Or, you know, consider test coverage.
SPEAKER_02Okay.
SPEAKER_01A development team might boast that like 100% of their code is covered by automated tests. In their minds, that is the absolute pinnacle of quality.
SPEAKER_02Right. They've checked every box.
SPEAKER_01But if those tests only validate isolated functions and the software behaves unpredictably when a real human being tries to complete a messy real-world task.
SPEAKER_02The user still hates it.
SPEAKER_01Exactly. They label the software as unreliable. Process is just an internal mechanism. It does not shield you from external judgment.
SPEAKER_02Aaron Powell The newsletter actually makes a very explicit point about Agile, despite it being this industry-dominating philosophy.
SPEAKER_01Yeah, it's quite candid about it.
SPEAKER_02It says Agile can enable quality. Sure. It can support a team in moving faster, but it does not inherently define quality. A user doesn't know if you work in two-week sprints or six-month waterfall cycles.
SPEAKER_01No, they really don't.
SPEAKER_02They only know if the software supports their daily workflow.
SPEAKER_01Aaron Powell If we connect this to the bigger picture, the core argument of the source material is that from the outside looking in, the entire universe of software engineering collapses into a single point of interaction.
SPEAKER_02Just that one moment.
SPEAKER_01Yeah. The architecture, the databases, the agile ceremonies, the late-night debugging sessions, all of it compresses down into the split-second experience of the user clicking a button.
SPEAKER_02Okay, so this is the ultimate question.
SPEAKER_01Play it on me.
SPEAKER_02If the tools don't equal quality and the hidden features are ignored, and the perfect agile process doesn't guarantee a good product, how on earth do engineers actually bridge this gap? Like how do you translate all that rigorous technical discipline into an experience the customer actually values?
SPEAKER_01Well, the author provides a pragmatic engineering checklist to solve exactly this problem.
SPEAKER_02A checklist.
SPEAKER_01But we need to look at it not as a rigid set of rules, but really as a translation layer between engineering effort and human experience.
SPEAKER_02Okay, let's go through it.
SPEAKER_01It covers five key areas, starting with purpose. And the fundamental question here is: does the system truly solve the problem?
SPEAKER_02Which sounds obvious, but I'm guessing it's really not.
SPEAKER_01It is incredibly difficult in practice. The danger is that engineers often validate complete features, but they fail to validate complete workflows.
SPEAKER_02Give me an example of that.
SPEAKER_01Okay, let me give you a scenario. A developer builds a complex data saving feature. In their isolated testing environment, the save button works 100% of the time.
SPEAKER_02Awesome. Feature done.
SPEAKER_01Right. The developer marks the task as complete and high quality. But the user isn't just trying to click save, they are trying to generate a massive end-of-month fiscal report.
SPEAKER_02Oh. And when they hit save on a data set that large, server times out. The server time's out.
SPEAKER_01Precisely. The feature works, but the workflow fails. The user experiences a 0% success rate.
SPEAKER_02And engineering might claim the system is functioning as designed, right?
SPEAKER_01Oh, they'll dismiss the massive file size as an edge case.
SPEAKER_02Right.
SPEAKER_01But as the newsletter points out, real-world edge cases are often central to how the user actually operates. If you don't understand the user's actual goal, you just build perfectly functioning features that solve the wrong problems.
SPEAKER_02Aaron Powell Which flows right into the second and arguably most frustrating point on the checklist for a lot of tech teams. Usability.
SPEAKER_01Usability is huge.
SPEAKER_02The core question here is: can the software be used without explanation? And the author notes that usability is almost always assumed by the team building it rather than actually verified.
SPEAKER_01Yeah, this is a classic example of the curse of knowledge.
SPEAKER_02What do you mean?
SPEAKER_01Well, the developer who wrote the back-end database query knows exactly how the data is structured, right? Sure. So when they build the user interface, they design a search bar that requires specific Boolean operators or complex filters. Because to them, that maps perfectly to the database logic.
SPEAKER_02Aaron Powell But the actual user sitting in a noisy office trying to find a client's file doesn't know what a Boolean operator is. They just type a normal sentence into the search bar, get zero results, and assume the software is broken.
SPEAKER_01Aaron Powell And this is why the newsletter insists that no amount of internal debate in a conference room can replace actual observation.
SPEAKER_02Right.
SPEAKER_01The developers are sitting in a quiet office with huge monitors, gigabit internet, and total knowledge of the system.
SPEAKER_02And the user might be on like a five-year-old laptop in a spotty Wi-Fi zone, panicked about a deadline.
SPEAKER_01Exactly. You have to observe where real people hesitate. Where do their eyes dart around the screen? Where do they make mistakes?
SPEAKER_02So what does this all mean? It means if you design a system and then have to stand over the user's shoulder saying, no, don't click there. You have to open this other tab first.
SPEAKER_01Your design has failed.
SPEAKER_02Your design has fundamentally failed. A system that requires a training manual or constant onboarding is by definition an unfinished system.
SPEAKER_01I'd take that a step further, actually.
SPEAKER_02Yeah.
SPEAKER_01If it requires a manual, the engineering team has essentially outsourced their design failures onto the user's cognitive load.
SPEAKER_02Oh, that's a brutal way to put it, but so true.
SPEAKER_01Now, if we move past usability, the third critical area is reliability.
SPEAKER_02Okay.
SPEAKER_01And this isn't just about trying to prevent failures, it's about how the software behaves when the real world inevitably throws a wrench into the gears.
SPEAKER_02Because things are gonna break, servers go down, network connections drop. Always. The question isn't if it fails, but how it fails. The checklist specifically highlights the concept of graceful degradation.
SPEAKER_01Yes. Let's look at how that actually works in practice.
SPEAKER_02Yeah.
SPEAKER_01Imagine an inventory management system used by warehouse workers.
SPEAKER_02Okay. Lots of scanning, fast-paced.
SPEAKER_01Right. If the central database server goes offline for, say, three minutes, a poorly designed system simply crashes. It throws up a terrifying error code, deletes the workers' current scanning session, and forces them to start over.
SPEAKER_02Which is incredibly frustrating. The user instantly loses trust in the tool.
SPEAKER_01Exactly. But with graceful degradation, the system expects the network to fail occasionally.
SPEAKER_02So instead of crashing, maybe it just quietly caches the scanned barcodes locally on the device.
SPEAKER_01Yes. It shows a little yellow banner saying offline mode, syncing paused, and lets the worker keep doing their job.
SPEAKER_02Aaron Powell That is the perfect distinction. The system degraded gracefully. It prioritized the user's workflow over the system's internal state.
SPEAKER_01And combined with clear, human-readable error handling, that is how you build trustworthiness. Users don't demand absolute magical perfection.
SPEAKER_02They just deeply, desperately rely on predictability.
SPEAKER_01Exactly.
SPEAKER_02Which brings us to the fourth dimension of the checklist performance. The question is: does it feel responsive in practice? And I really want to highlight the word feel there.
SPEAKER_01Because that's the whole ballgame.
SPEAKER_02It is. Performance is universally measured by engineers using strict technical metrics. Milliseconds of latency, server CPU load, database query times.
SPEAKER_01Right, objective numbers.
SPEAKER_02But performance is actually experienced through human perception. And those two things are not always perfectly aligned.
SPEAKER_01No, they're really not. A system can technically meet every single functional requirement on a spreadsheet. Right. But if clicking a button introduces like a 500 millisecond delay, and that delay interrupts the user's state of flow 50 times an hour, they are gonna hate using the product. They will absolutely hate it. The crucial warning the author gives here is about architecture. Late stage performance tuning, you know, trying to optimize code right before launch almost never compensates for structural decisions that ignored performance on day one.
SPEAKER_02So you can't just fix it at the end.
SPEAKER_01No. If you build a massive bloated architecture, you cannot just sprinkle speed on top of it at the end.
SPEAKER_02Right.
SPEAKER_01Performance has to be defined by acceptable human experience from the very first blueprint. You have to use techniques like optimistic UI updates.
SPEAKER_02What's that?
SPEAKER_01It's where the button instantly reacts to the user's click, maybe changing color or showing a check mark, even if the server is still processing the data in the background.
SPEAKER_02Ah, just to maintain that feeling of speed.
SPEAKER_01Exactly. It's all about perception.
SPEAKER_02And the final critical piece of the translation checklist is security. Is it built into the system from the foundation or is it bolted onto the outside as an afterthought?
SPEAKER_01Aaron Powell Well, we talked earlier about security being an invisible assumption, right?
SPEAKER_02Yes, the plumbing.
SPEAKER_01The way you achieve that invisibility is through deep integration. You have to map out trust boundaries and data flows before a single line of code is written.
SPEAKER_02Right.
SPEAKER_01If you know exactly how data moves through the internal microservices, you can secure those specific pathways tightly behind the scenes.
SPEAKER_02But if you don't do that mapping early on, you reach the end of the project and realize the whole house is vulnerable. Yep. So what do you do? You bolt a massive padlock onto the front door, you force the user to deal with multi-factor authentication and VPN logins for every single minor interaction.
SPEAKER_01You basically create usability for security.
SPEAKER_02Right, creating a massive amount of friction.
SPEAKER_01And that friction destroys the user experience. When security is done correctly, it protects the data without ever demanding the user's attention. It remains completely out of sight.
SPEAKER_02Which leads us to the absolute paradox at the heart of this entire deep dive.
SPEAKER_01Let's hear it.
SPEAKER_02The paradox of true quality. Let's trace this out. If a team of software engineers takes this entire pragmatic checklist, they validate purpose, they ruthlessly observe usability, they design for graceful reliability, they architect for perceived performance, and they bake in invisible security. If they execute all of that perfectly, what is the final result?
SPEAKER_01The result is that the software completely disappears.
SPEAKER_02It vanishes. When software quality reaches its absolute highest level, the user stops seeing the software entirely.
SPEAKER_01They really do.
SPEAKER_02They don't jump on social media to praise the elegant database queries. They don't marvel at how cleanly the APIs are routing their requests.
SPEAKER_01No, they just do their work.
SPEAKER_02Exactly. They enter their data, they generate their reports, they communicate with their teams, and they do it without a single microsecond of hesitation. The ultimate defining characteristic of true quality is the total, absolute absence of friction.
SPEAKER_01This raises an important question about the psychological toll this takes on the people building the software.
SPEAKER_02What do you mean?
SPEAKER_01Well, it requires a massive, almost unnatural shift in ego for an engineer. Think about traditional craftsmanship. A master carpenter wants you to open the drawer and admire the intricate dovetail joints.
SPEAKER_02Oh, for sure. They want you to see their hard work.
SPEAKER_01But the software engineer's dovetail joints are buried deep in a Git repository where no customer will ever see them. Right. The human instinct is to want praise for your cleverness for the long hours you spent optimizing a complex algorithm. But in this field, if the user notices your work, it usually means something is broken, slow, or confusing.
SPEAKER_02That is wild to think about.
SPEAKER_01The beautiful, frustrating paradox of software engineering is that the more effort you invest in doing things perfectly, the less visible your effort becomes to the outside world. Your ultimate crowning achievement is achieving total invisibility.
SPEAKER_02It is a profound shift away from vanity metrics. You have to let go of wanting applause for the tools you used or the agile sprints you completed, and just find deep professional satisfaction in the silent, uninterrupted workflow of a total stranger.
SPEAKER_01Beautifully said.
SPEAKER_02Quality is not the code that is written. Quality is the experience the customer receives. Everything else is just the messy reality of how we get there.
SPEAKER_01But if we truly accept that premise that the absolute pinnacle of software quality is invisibility and the total absence of friction, it leaves us with one final deeply provocative puzzle to think about.
SPEAKER_00Ooh.
SPEAKER_01Yeah. If true quality is literally invisible, how on earth do sales and marketing teams successfully sell it?
SPEAKER_02Right.
SPEAKER_01How do you convince a buyer to write a massive check for the absence of crashes, the absence of confusion, and the absence of friction when what they are actively demanding is a tangible list of new features?
SPEAKER_02How do you put a price tag on nothing going wrong? That is an incredible question to chew on, and maybe a topic for a whole different deep dive. Thank you so much for joining us. Joining us as we explored the hidden world of software quality. We will catch you next time.
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