1. Schedule, schedule, schedule rules the day. In my career of 30 years this has always been the most important for management. My highest job ratings have always come from finishing ahead of schedule. Never has it been for enhancing quality.
2. If we emphasized quality as much as we emphasize schedule we would not have any quality problems.
3. Can't hide missing schedule but quality problems can be hidden and swept under the rug for a time.
4. Keep missing schedule and you get fired.
5. Keep missing quality and you many times enhance your own job security so that you can fix the quality problems.
Quality sucks doesn't it? I do not believe quality is a dead concept. Most prudent engineers want high quality products by nature. Engineers work with products before they are produced so engineers know what quality of product they are producing before anyone else uses it. Why would an engineer put out a product with low quality? Criminal, insanity, or ignorance. Criminal as in the engineer knowing lets a low quality product go into production. Why? For the engineer’s or others (They that shalln’t be named) benefit (“Benefit” covers several concepts from profit to survival). Insanity in that the engineer or others (They that shalln’t be named, again) has convinced themselves that the product is “high quality” (“Convinced” covers several concepts from willful blindness to System Acceptance). Ignorance is more likely as in no one knows there is a quality “problem” until there is a problem (“knows” covers several concepts from rush jobs to limited testing). Direct any questions to these three and you will have some good questions.
What time (in percentage of development time) would you -as an engineer- suggest to really make the user interface properly done? (Note: I find this often SO HORRIBLE, even with modern products. I tried to install a stupid label printer lately, heck, what a non-intuitive horrible peace of shabby programming! )
The sub-conversation about scaling the customer hits home for me, the assumption about writing a questionnaire assumes 10 questions can be composed about quality when the very word is understood to mean so many things to so many differently-hatted engineers. Good luck.
BTW (scaling a listener) Any time I explain a technical issue I have to know how much fundamental information is already understood so the listener can understand the detail. Many engineers I've seen in action are awfully short with people that require more explanation/starting simpler than they care to take time to explain. Result: an expectation that "Engineers are aloof!" This is why people like Jim Williams and Bob Pease are so revered by other engineers, they always seemed to be willing (per the recent funerary testimonies) to instruct rather than assume. If only we could all remember that questions asked in ignorance are opportunities to erase the ignorance!
Management has caught on to us...whenever I have had this conversation in recent years, it winds up being, "You have no choice...we REQUIRE all three!" And the unspoken part: or you will be fired, and we will find someone who Will sign up to all three, regardless of whether or not it is physically possible...
Perhaps the questions could start by probing some underlying issues:
1) Ego. Are we living in a post-technical era where decisions are controlled by big-business, big-banks, big beauracrats, big egoes? A lack of quality isn't a technical/scientific problem at all. (Paul hit this nail on the head and I've had similar experiences.)
2) Honesty. Too many problems (quality and otherwise) get swept "away" through use of deception, "creative" accounting (or whatever), mis-representation and out right lies. You just keep building a house of cards.
3) Complexity. Today's highly complex products (especially software aspects) are creating an environment where its impossible for any creator or user to understand the whole thing. Complex processes are then expected to fill the void but the processes themselves are getting too complex and suffering the same quality issues as the products they are creating and supporting. We need to simplify!
4) Heart attitude. To what extent would respondents agree with the 1900+ year old quote, "Whatever you do, work at it with all your heart, as though you were working for the Lord and not for people." Do I have any moral basis for doing things right?
I hate it when someone tells me that we don't want to "over design". This one attitude alone is causing "quality to suck".
Most of the time putting that extra design effort doesn't cost that much and actually ends up costing less because re-design (and lawsuits) are avoided later.
COME ON FELLOW ENGINEERS:
NEVER SAY.. "WE DON'T WANT TO OVERDESIGN."
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.