Software products are not boxes of cornflakes
The thing about building software is that you are not selling cornflakes.
Consider for a moment a burnt cornflake. One burnt cornflake in a packet will only make it into one bowl, and therefore disappoint just one customer.
Even then, it’s not going to spoil their breakfast. Recovery is just a spoon flick away.
What’s more, there’s an understanding on the part of the customer:
“They must make millions of cornflakes! Understandable a few cremated ones would slip through the net.”
And even if there’s a customer helpline printed on the side of the box, only the saddest of souls would ever call over a burnt cornflake.
Of course, software products are not boxes of cornflakes.
One bad code commit could affect everyone.
Internal server errors, by their very nature, means the user experience is irrecoverable. The best you can do is a nicely designed and apologetic error page.
What’s more, people’s expectation of software is high. They are used to applications such as Word, which for all its failures is pretty robust. You may not be able to figure out the Mail Merge stuff, but at least it doesn’t crash.
So if you end up committing a burnt cornflake to your codebase — and it slips under the testing radar — you’re going to get some really frustrated customers hitting your support channels.
So far, so obvious? Not always.
When you’re working on a product every day, it’s very easy to compartmentalise bits of the experience.
“The sign up process works really well.”
“The new home page looks sweet!”
“The subscription page is causing some confusion amongst customers.”
“That radio button thing has never worked well, but since nobody’s actually sure how it should work, we can get away with it for now.”
But, for customers, there are no parts of the experience — only the whole.
Users quickly forget all the nice interactions, clarity of copy, and speed of response if the system deals them a 500. Summed up nicely here, by @dhh.