I cannot image where we would be without automated testing, continuous integration, Rspec, Cucumber and all the myriad tools and techniques available to build dependable, quality software product. But this doesn’t mean issues and errors don’t slip through.
A few months back I implemented a practice that I had considered using for years. I’d never done it because of the pushback I received from the teams I worked with. I regret not having done it years ago.
They may not be aware of it, but our users never encounter an error on their own. That error lands like a thud in every development inbox. It’s a thud because it’s unexpected. It’s a thud because it’s a call to action to the team: “Make it stop.”
When we first started this practice, there were dozens and dozens of errors a day. We had to categorize, tag, and prioritize them. It took several weeks to reclaim our inboxes. And we had to do this while pushing out new features. So there was a constant tug-of-war between current user experience and adding new value.
But one day came the silence of no errors. And it felt good, because we knew that’s how our users must feel — even if they didn’t know quite how or why.
This isn’t the same as collecting errors are scanning logs, which can be easily forgotten or simply deprioritized. This might be difficult for huge products and strained teams. But this is something I’ll strive for with every new product, regardless of the initial resistance from the team.
It doesn’t feel right having the wrong answer for this question: “Do your users face your errors in solitude?”