So for my first substantive post, I want to talk about something which is near and dear to my heart. Something which sets the tone and foundation for this entire blog. Something that was instilled into my brain years and years ago by a man whom I would consider a valuable mentor – and someone who is truly dedicated to the measure of quality, down to their innermost core.
Let’s kick this off with a question. One of the most contentious questions in business.
What is quality?
How you approach the answer to this question determines the starting point for how you answer this next one:
What is software quality?
I know what you’re thinking – too broad for a blog post. You’re right. Heck, so many books have been written on this topic I probably couldn’t keep all of them on my bookshelf.
Let’s look at some key questions that we, as software developers, should seriously be considering as we produce and improve our digital product. Again, most of these questions arose from the fundamentals of manufacturing quality, Six Sigma, and Lean philosophy, but need to be rehashed to apply to today’s fast-paced world of application design and digital product development.
How do we know that the application we’ve built is of high quality?
Who determines this?
Can it be measured?
What if a different development team takes over the product, and they say we are wrong? Who is right? What is the criteria for deciding?
Can I look at a codebase and “feel” the quality of the code, or does experience and instinct have no place in a world packed with data analytics, metrics, KPI’s, and issue trackers?
By the way, does any of this matter if I get slapped with a requirements document and am told to make this feature fast and cheap because management wants to get this thing out the door?
Over the next few weeks, I’m going to give my thoughts on the topic, and I’ll try to refrain from being over academic. But for now, I want to dig into some pretty fundamental concepts.
Any Six Sigma expert worth their salt is going to throw Deming at you, and he would say “The customer’s definition of quality is the only one that matters.”
True, but who is the customer?
During my transition from Six Sigma to Agile/Scrum, I realized any time Six Sigma says ‘Customer’, it can be translated to ‘End User’.
Which means our users‘ definition of quality is the only one that matters?
You see, a fundamental part of Six Sigma methodology is identifying customers in different “domains”, if you will. The first line drawn is between internal and external customers. An external customer can be a wholesaler, retailer, or end consumer (this is probably closer to the end user translation).
A critical part of doing business and maintaining high quality standards is measuring, and investing in, your internal customers. This can be a supplier who makes your goods, the purchase order department, and even customer service representatives. For some of you, this might be a slight philosophy change. Yes, after your product goes live, your responsibility goes beyond profits and five star reviews. Once its out there, it needs to be supported, have its reputation (and by extension, your brand) maintained, and continue to “delight your customers” (following the Deming phraseology). In the tech world, this is more common knowledge, but you would be surprised at the number of traditional consumer goods companies which cease caring about their product once it leaves the warehouse freight bay.
I’m going to cut myself off here for this week. I think we touched on a few areas which deserve more attention and I’d like to dedicate individual posts for some deeper thought.
This one’s for you, J.W!
(Credit for the image goes to Tesseract – a British Progressive Metal group, if you’re a metalhead. I rather enjoy the melodic tones, and their drummer keeps things mixed up and fresh!)