Summary: <br> What is Quality Software and how do we ensure we are Delivering Quality Software?<br> <br> <br> Transcript<br> Clayton Hunt: This week we're talking about quality and how we can deliver quality software. <br> <br> Jon Ash: So quality software that's what the QA departments for?<br> <br> John Callaway: Quality is everyone's responsibility. I heard ... I think either on a podcast or on a YouTube video or maybe just on Twitter, I might've read that you're not paid to deliver code. You're paid to put code into production. I would take that a step further and say, you're paid to deliver value. Whether that is a right code and produce some functionality and put that into production where it is being useful to someone or some process, or if it's just a configuration setting or it's a new manual process of Pencil and paper.<br> <br> Clayton Hunt: Yeah, companies don't want code they want or they think they want software because they think that it can solve a problem that they have or optimize a process that they already ... That's in existence. They don't actually care about the code at all.<br> <br> John Callaway: Stepping back for just a minute, what are we trying to do to find when we use the term quality?<br> <br> Clayton Hunt: Well, the first thing that always comes to my mind is quality software. A software that does what the company needs with limited breakdown. So I mean, bugs happen, you can't get rid of all the bugs. But five ninths worth of operation is really what we shoot for most of the time.<br> <br> Jon Ash: And I would also add to that the ability to extend that code into new functionality that, that the business might need. So, you want the software to remain software and not just another form of hardware, even if it can stay running as hardware. Right.<br> <br> John Callaway: So something that we'll continue to deliver value as the needs of the business change?<br> <br> Jon Ash: Correct.<br> <br> John Callaway: So by that, do you mean that it's something that's easily maintainable and easily extendable or, what more do you mean by that?<br> <br> Jon Ash: Yeah, I think the maintainability and extendability are where those two pieces are what I'm talking about. Yeah, I mean I think that you just ... It needs to be able to be modified, right? So either add features to that or modify the way that, that system things that are integrated with it? There are definitely different ways of going about that, right? You don't necessarily have to change the literal code that's running. You could add ... It could be a part of a system where you could extend it by adding other modules or other pieces of code, right? The way that you maintain it. But the code itself has to be able to be maintained and extended, and flex with whatever new requirements however the business changes, how the world changes, 'cause code really, once it's written, the computer should be able to continue doing that exactly the same way for forever.<br> <br> Jon Ash: I mean, assuming you don't have things like, memory leaks and other issues, right? If it's quality code that's running well, it'll run for forever. But if you can't change it, then you're going to have to go and stop that code to introduce a new system because the old one was too inflexible.<br> <br> John Callaway: It sounds like you've been answering the question, of why Clean Code matters. Clean Code is a term that any followers of Uncle Bob would be familiar with, but it basically means code that is maintainable and flexible enough to change with the business needs. Are there any other reasons why Clean Code matters? So other than keeping up with the business, why would Clean Code matter?<br> <br> Clayton Hunt: To Ash's point? I think it, has to do with,
