Getting disciplined about embedded software development: Part 1 - Any idiot can write code
Quality Is Nice As Long As It's Free
The cost data just described is correlated to a quality level. Since few embedded folks measure bug rates, it's all but impossible to add the quality measure into the anecdotal costs. But quality does indeed have a cost.
We can't talk about quality without defining it. Our intuitive feel that a bug-free program is a high quality program is simply wrong. Unless you're using the Netscape "give it away for free and make it up in volume" model, we write firmware for one reason only: profits. Without profits the engineering budget gets trimmed. Without profits the business eventually fails and we're out looking for work.
Happy customers make for successful products and businesses. The customer's delight with our product is the ultimate and only important measure of quality.
Thus: the quality of a product is exactly what the customer says it is .
Obvious software bugs surely mean poor quality. A lousy user interface equates to poor quality. If the product doesn't quite serve the buyer's needs, the product is defective.
It matters little whether our code is flaky or marketing overpromised or the product's spec missed the mark. The company is at risk due to a quality problem so we've all got to take action to cure the problem.
No-fault divorce and no-fault insurance acknowledge the harsh realities of transmillennium life. We need a no-fault approach to quality as well, to recognize that no matter where the problem came from, we've all got to take action to cure the defects and delight the customer.
This means when marketing comes in a week before delivery with new requirements, a mature response from engineering is not a stream of obscenities. Maybe just maybe marketing has a point. We make mistakes (and spend heavily on debugging tools to fix them). So do marketing and sales.
Substitute an assessment of the proposed change for curses. Quality is not free. If the product will not satisfy the customer as designed, if it's not till a week before shipment that these truths become evident, then let marketing and other departments know the impact on the cost and the schedule.
Funny as the Dilbert comic strip is, it does a horrible disservice to the engineering community by reinforcing the hostility between engineers and the rest of the company.
The last thing we need is more confrontation, cynicism, and lack of cooperation between departments. We're on a mission: make the customer happy ! That's the only way to consistently drive up our stock options, bonuses, and job security.
Unhappily, Dilbert does portray too many companies all too accurately. If your outfit requires heroics all the time, if there's no (polite) communication between departments, then something is broken. Fix it or leave.
Loading comments... Write a comment