Invisible Features

During one of our recent all hands meetings I was asked which features are mostly used by customers in our products. And the answer was a bit counterintuitive, but honest to the root.

Quality.

Quality is invisible (when you have it). You simply acknowledge it is normal. After all this is how the product is supposed to work. Also using a high quality product makes an impression it is simple - it just works. When there are no issues - in software products they exhibit typically as freezes, crashes or behaviors being fixed by reboots. Reboots are very often the cure and many of them go even unnoticed. Unless this is a light that flashes above your head when it reboots (yes, lights are software products now, very complex software products).

And quality - in its roots - is a mindset. 

It is also very expensive. But in the end I believe (the mindset!) it makes the difference.

We have many painful examples of chasing quality issues down to their root causes. One example - among many thousands products running in filed we noticed a very small percentage of them were reset by watchdogs after about 50 days (0x3FFFFF seconds to be exact). Finding the root cause was long and costly, but in the end we got it. The result has been a pull request to FreeRTOS-Kernel (still open when I'm writing this).

The bottom line is that ultimately quality and performance are the differentiators between software and really good software. It takes a lot of effort to iron out all the wrinkles - especially in complex low level embedded code. And first it takes the mindset to even start doing that. Bugs like the one mentioned above will never surface in customer demos and typical testing. But ultimately they define whether the software is rock solid dependable or not.