Ed Horch commented on an answer I posted on Quora, suggesting I add Quality is Free by Philip B. Crosby to my answer. I have never read that book before, so I went ahead and bought a used copy. This book is stirring up things in my head about quality as it relates to software development, and I want to jot down a few notes, before I forget them.
Another way quality was book in the book, and I'm paraphrasing here
Most of what your customer expects is what they have been told. There's what you have promised them. All your marketing materials, demos, product documentation, etc.
There's what they expect from your product that you haven't explicitly told them. If you're building a better word processor, then your users might expect it to work similar to Microsoft Word. And in the absence of being told, your customers might make up their own requirements, based on past experiences.
And your customers expect your software to work, regardless of how many others are using it, if you're building online software.
What have you promised?
The marketing materials, demos, and product documentation are the explicit things where you make promises to your client, if you provide them. If you have an SLA, that spells out in explicit detail what your clients can expect. Your brand also makes promises of your product - for example, I would expect all Apple products to be well polished and just work, regardless of what product they produce.
How to get Quality for Free in Software Development?
That's an interesting question, and I'm not claiming I have the answer. But I do think there is something to the idea of "Quality is Free", and I think it align's pretty well with the agile / lean development practices. Here's what this means to me.
We can measure quality by executing BDD style tests for use cases. To me, a use case is a promise for how a feature will behave - a promise to our customers.
We need to tests for non-functional requirements to have quality. To do this, we need to plan for usage patterns, and design to support that load.
We can start thinking about testing for quality before writing a single line of code. Imagine that the feature is finished, and you want to demo it to a prospective client. What language would you use? What is your sales pitch? However you want to sell it, those selling points are your promise to your clients, and can be captured in tests, before writing the software!
I'd love to hear about how "Quality is Free" has influenced your software development practices.
What is Quality?
According to Crosby
Quality is conformance to requirementsThat's a very simple definition of quality, and at first glance it might not seem revolutionary. And it's in stark contrast to how Prisig tries to define quality in Zen And The Art of Motorcycle Maintenance, driving the main character mad trying to define exactly what quality is. I really like Crosby's definition of quality. I'll try to expand on that a little bit.
Another way quality was book in the book, and I'm paraphrasing here
Quality is when a customer gets what they expectWhat are your customers expectations?
Most of what your customer expects is what they have been told. There's what you have promised them. All your marketing materials, demos, product documentation, etc.
There's what they expect from your product that you haven't explicitly told them. If you're building a better word processor, then your users might expect it to work similar to Microsoft Word. And in the absence of being told, your customers might make up their own requirements, based on past experiences.
And your customers expect your software to work, regardless of how many others are using it, if you're building online software.
What have you promised?
The marketing materials, demos, and product documentation are the explicit things where you make promises to your client, if you provide them. If you have an SLA, that spells out in explicit detail what your clients can expect. Your brand also makes promises of your product - for example, I would expect all Apple products to be well polished and just work, regardless of what product they produce.
How to get Quality for Free in Software Development?
That's an interesting question, and I'm not claiming I have the answer. But I do think there is something to the idea of "Quality is Free", and I think it align's pretty well with the agile / lean development practices. Here's what this means to me.
We can measure quality by executing BDD style tests for use cases. To me, a use case is a promise for how a feature will behave - a promise to our customers.
We need to tests for non-functional requirements to have quality. To do this, we need to plan for usage patterns, and design to support that load.
We can start thinking about testing for quality before writing a single line of code. Imagine that the feature is finished, and you want to demo it to a prospective client. What language would you use? What is your sales pitch? However you want to sell it, those selling points are your promise to your clients, and can be captured in tests, before writing the software!
I'd love to hear about how "Quality is Free" has influenced your software development practices.
Thank you for sharing this thought-provoking perspective. It's invigorating to encounter a different take on the topic. General Contractor Services
ReplyDelete