What Really Defines High-Quality Software?

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.

Transcript

SPEAKER_00 0:29

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_02 2:43

Imagine spending like two years and five million dollars building the most architecturally flawless, perfectly secure software platform on the planet.

SPEAKER_01 2:53

Oh, a total masterpiece of engineering.

SPEAKER_02 2:56

Right. 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_01 3:03

Yeah. Which happens all the time.

SPEAKER_02 3:04

It 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_01 3:15

Aaron Powell, which is a fantastic source, by the way.

SPEAKER_02 3:17

Aaron 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_01 3:29

Aaron 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_02 3:53

Okay. Let's unpack this. Because the newsletter points out a fundamental shift in perspective that kind of ruins that entire paradigm.

SPEAKER_01 4:00

Aaron Powell It really does.

SPEAKER_02 4:01

Engineers 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_01 4:11

Aaron Powell None at all.

SPEAKER_02 4:12

Aaron Ross Powell Right. So they define quality entirely by how it is experienced.

SPEAKER_01 4:16

Aaron 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_02 4:31

Aaron Ross Powell Like, does this do what I need it to do? Aaron Powell Exactly.

SPEAKER_01 4:34

Is 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_02 4:47

Trevor 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_01 4:54

Oh, spending thousands of dollars on a blade.

SPEAKER_02 4:57

Exactly. 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_01 5:05

The diner isn't paying for the knife.

SPEAKER_02 5:07

No, 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_01 5:18

Use universal.

SPEAKER_02 5:19

Yeah. 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_01 5:29

Right. The context of the work changes dramatically, obviously. But the human perception of friction does not.

SPEAKER_02 5:35

Yeah.

SPEAKER_01 5:36

If the software solves the problem without making the user think about the software itself, it's perceived as high quality.

SPEAKER_02 5:42

And if it introduces confusion, it's bad.

SPEAKER_01 5:45

Simple as that. The tool itself is totally irrelevant to the experience.

SPEAKER_02 5:48

Aaron Powell Wait, I have to push back on this premise just a little bit.

SPEAKER_01 5:51

Okay, go for it.

SPEAKER_02 5:52

If 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_01 6:03

Like what?

SPEAKER_02 6:05

Well, take security. I mean, we hear about data breaches every single day, right?

SPEAKER_00 6:09

It's true do.

SPEAKER_02 6:10

Isn't top-tier airtight security a massive selling point? Wouldn't a customer actively praise an app that perfectly protects their data?

SPEAKER_01 6:18

You 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_02 6:33

It's huge.

SPEAKER_01 6:34

But to the customer, security and reliability for that matter, they are assumptions. They are not features.

SPEAKER_02 6:40

Assumptions, meaning the user just fundamentally expects the door to be locked when they walk away.

SPEAKER_01 6:45

Exactly. Think about the plumbing in your house.

SPEAKER_02 6:47

Okay.

SPEAKER_01 6:47

You 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_02 6:56

Right. I'm not writing a thank you note to the city planner. Trevor Burrus, Jr.

SPEAKER_01 7:00

You 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_02 7:09

It just sits invisibly in the background.

SPEAKER_01 7:11

Yep. But the absolute millisecond, it fails. It instantly and catastrophically erodes all trust.

SPEAKER_02 7:18

Aaron 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_01 7:27

The harsh reality. And this actually maps perfectly to formal engineering standards, even if the vocabulary is different.

SPEAKER_02 7:34

How so?

SPEAKER_01 7:35

The source text brings up the ISO IEC 25010 quality model.

SPEAKER_02 7:40

That sounds like a mouthful.

SPEAKER_01 7:41

No, it's a massive formal framework. It categorizes software quality into dimensions like functional suitability, usability, performance efficiency, and security.

SPEAKER_02 7:50

Which honestly sounds incredibly dry and technical.

SPEAKER_01 7:53

It 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_02 8:17

And customers just emphasize the invisible assumption of it.

SPEAKER_01 8:20

Exactly.

SPEAKER_02 8:21

Here's where it gets really interesting, though.

SPEAKER_01 8:23

Okay.

SPEAKER_02 8:23

Because 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_01 8:34

The way teams work.

SPEAKER_02 8:35

Right. I'm talking to agile, entire tech empires are built on agile frameworks, scrum masters, camban boards, you know, two-week sprints.

SPEAKER_01 8:45

Oh, yeah, a massive industry.

SPEAKER_02 8:46

Are 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_01 8:56

It absolutely does not.

SPEAKER_02 8:57

Wow.

SPEAKER_01 8:58

The trap here is that engineers naturally gravitate toward what they can control.

SPEAKER_02 9:02

Which makes sense.

SPEAKER_01 9:03

Right. 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_02 9:17

I see. So you could have a beautifully organized sprint, perfect code reviews, maybe an elegant architecture.

SPEAKER_01 9:24

Yep.

SPEAKER_02 9:24

But 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_01 9:32

100%. Or, you know, consider test coverage.

SPEAKER_02 9:36

Okay.

SPEAKER_01 9:36

A 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_02 9:44

Right. They've checked every box.

SPEAKER_01 9:45

But 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_02 9:55

The user still hates it.

SPEAKER_01 9:57

Exactly. They label the software as unreliable. Process is just an internal mechanism. It does not shield you from external judgment.

SPEAKER_02 10:04

Aaron Powell The newsletter actually makes a very explicit point about Agile, despite it being this industry-dominating philosophy.

SPEAKER_01 10:10

Yeah, it's quite candid about it.

SPEAKER_02 10:12

It 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_01 10:25

No, they really don't.

SPEAKER_02 10:26

They only know if the software supports their daily workflow.

SPEAKER_01 10:29

Aaron 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_02 10:42

Just that one moment.

SPEAKER_01 10:43

Yeah. 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_02 10:53

Okay, so this is the ultimate question.

SPEAKER_01 10:55

Play it on me.

SPEAKER_02 10:56

If 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_01 11:13

Well, the author provides a pragmatic engineering checklist to solve exactly this problem.

SPEAKER_02 11:17

A checklist.

SPEAKER_01 11:19

But 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_02 11:27

Okay, let's go through it.

SPEAKER_01 11:28

It covers five key areas, starting with purpose. And the fundamental question here is: does the system truly solve the problem?

SPEAKER_02 11:36

Which sounds obvious, but I'm guessing it's really not.

SPEAKER_01 11:39

It is incredibly difficult in practice. The danger is that engineers often validate complete features, but they fail to validate complete workflows.

SPEAKER_02 11:47

Give me an example of that.

SPEAKER_01 11:48

Okay, 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_02 11:58

Awesome. Feature done.

SPEAKER_01 11:59

Right. 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_02 12:10

Oh. And when they hit save on a data set that large, server times out. The server time's out.

SPEAKER_01 12:16

Precisely. The feature works, but the workflow fails. The user experiences a 0% success rate.

SPEAKER_02 12:21

And engineering might claim the system is functioning as designed, right?

SPEAKER_01 12:25

Oh, they'll dismiss the massive file size as an edge case.

SPEAKER_02 12:29

Right.

SPEAKER_01 12:30

But 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_02 12:44

Aaron Powell Which flows right into the second and arguably most frustrating point on the checklist for a lot of tech teams. Usability.

SPEAKER_01 12:51

Usability is huge.

SPEAKER_02 12:52

The 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_01 13:03

Yeah, this is a classic example of the curse of knowledge.

SPEAKER_02 13:06

What do you mean?

SPEAKER_01 13:07

Well, 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_02 13:22

Aaron 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_01 13:35

Aaron Powell And this is why the newsletter insists that no amount of internal debate in a conference room can replace actual observation.

SPEAKER_02 13:42

Right.

SPEAKER_01 13:43

The developers are sitting in a quiet office with huge monitors, gigabit internet, and total knowledge of the system.

SPEAKER_02 13:50

And the user might be on like a five-year-old laptop in a spotty Wi-Fi zone, panicked about a deadline.

SPEAKER_01 13:57

Exactly. You have to observe where real people hesitate. Where do their eyes dart around the screen? Where do they make mistakes?

SPEAKER_02 14:05

So 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_01 14:14

Your design has failed.

SPEAKER_02 14:15

Your design has fundamentally failed. A system that requires a training manual or constant onboarding is by definition an unfinished system.

SPEAKER_01 14:24

I'd take that a step further, actually.

SPEAKER_02 14:25

Yeah.

SPEAKER_01 14:26

If it requires a manual, the engineering team has essentially outsourced their design failures onto the user's cognitive load.

SPEAKER_02 14:33

Oh, that's a brutal way to put it, but so true.

SPEAKER_01 14:41

Now, if we move past usability, the third critical area is reliability.

SPEAKER_02 14:46

Okay.

SPEAKER_01 14:47

And 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_02 14:56

Because 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_01 15:10

Yes. Let's look at how that actually works in practice.

SPEAKER_02 15:13

Yeah.

SPEAKER_01 15:13

Imagine an inventory management system used by warehouse workers.

SPEAKER_02 15:17

Okay. Lots of scanning, fast-paced.

SPEAKER_01 15:18

Right. 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_02 15:32

Which is incredibly frustrating. The user instantly loses trust in the tool.

SPEAKER_01 15:36

Exactly. But with graceful degradation, the system expects the network to fail occasionally.

SPEAKER_02 15:41

So instead of crashing, maybe it just quietly caches the scanned barcodes locally on the device.

SPEAKER_01 15:47

Yes. It shows a little yellow banner saying offline mode, syncing paused, and lets the worker keep doing their job.

SPEAKER_02 15:55

Aaron Powell That is the perfect distinction. The system degraded gracefully. It prioritized the user's workflow over the system's internal state.

SPEAKER_01 16:04

And combined with clear, human-readable error handling, that is how you build trustworthiness. Users don't demand absolute magical perfection.

SPEAKER_02 16:14

They just deeply, desperately rely on predictability.

SPEAKER_01 16:17

Exactly.

SPEAKER_02 16:18

Which 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_01 16:27

Because that's the whole ballgame.

SPEAKER_02 16:28

It is. Performance is universally measured by engineers using strict technical metrics. Milliseconds of latency, server CPU load, database query times.

SPEAKER_01 16:38

Right, objective numbers.

SPEAKER_02 16:39

But performance is actually experienced through human perception. And those two things are not always perfectly aligned.

SPEAKER_01 16:45

No, 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_02 17:16

So you can't just fix it at the end.

SPEAKER_01 17:18

No. If you build a massive bloated architecture, you cannot just sprinkle speed on top of it at the end.

SPEAKER_02 17:25

Right.

SPEAKER_01 17:25

Performance has to be defined by acceptable human experience from the very first blueprint. You have to use techniques like optimistic UI updates.

SPEAKER_02 17:33

What's that?

SPEAKER_01 17:34

It'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_02 17:43

Ah, just to maintain that feeling of speed.

SPEAKER_01 17:46

Exactly. It's all about perception.

SPEAKER_02 17:48

And 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_01 17:56

Aaron Powell Well, we talked earlier about security being an invisible assumption, right?

SPEAKER_02 18:00

Yes, the plumbing.

SPEAKER_01 18:01

The 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_02 18:11

Right.

SPEAKER_01 18:12

If you know exactly how data moves through the internal microservices, you can secure those specific pathways tightly behind the scenes.

SPEAKER_02 18:19

But 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_01 18:37

You basically create usability for security.

SPEAKER_02 18:40

Right, creating a massive amount of friction.

SPEAKER_01 18:42

And 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_02 18:59

Which leads us to the absolute paradox at the heart of this entire deep dive.

SPEAKER_01 19:03

Let's hear it.

SPEAKER_02 19:04

The 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_01 19:26

The result is that the software completely disappears.

SPEAKER_02 19:29

It vanishes. When software quality reaches its absolute highest level, the user stops seeing the software entirely.

SPEAKER_01 19:36

They really do.

SPEAKER_02 19:37

They 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_01 19:45

No, they just do their work.

SPEAKER_02 19:46

Exactly. 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_01 20:00

This raises an important question about the psychological toll this takes on the people building the software.

SPEAKER_02 20:05

What do you mean?

SPEAKER_01 20:06

Well, 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_02 20:19

Oh, for sure. They want you to see their hard work.

SPEAKER_01 20:21

But 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_02 20:41

That is wild to think about.

SPEAKER_01 20:43

The 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_02 20:57

It 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_01 21:10

Beautifully said.

SPEAKER_02 21:11

Quality 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_01 21:20

But 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_00 21:33

Ooh.

SPEAKER_01 21:34

Yeah. If true quality is literally invisible, how on earth do sales and marketing teams successfully sell it?

SPEAKER_02 21:40

Right.

SPEAKER_01 21:40

How 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_02 21:51

How 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_00 22:16

Thank 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.