The first "real" computer bug
On this day in 1947, a moth got stuck between the relays on the Harvard Mark II. Grace Hopper, after removing the moth, put it in the computer logbook with the note of “First actual case of a bug being found”. If only it was that easy to identify and remove a bug today!
As a software company, bugs are an unfortunate fact of our life. When you combine supported device and version types with actual usage, it quickly runs into millions of scenarios. All the QA and regression testing can never account for all of this. Clearly we are not unique in this situation. Here are three processes we’ve found to help us manage bugs:
- Invest the time to get alert sensitivity right
I recently saw an organization where every error was triggering text alerts - and then it typically sent at least 4 text messages per issue. I asked why and no one knew. End result? The support team tended to ignore them - “they’ll call me if it’s important”. Reviewing your alert triggers and sensitivity is an ongoing process, not a set and forget activity. - Clear, human-to-human communication
We’ve all been there with the automated email telling us the problem is important. That is BS. An automated email is simply a glorified Out of Office response. Yes, staffing for this level of support costs more, and your VCs will tell you to cut unit costs but consider this: a person has taken the time to tell you about a problem with your product. The least you can do is respond to them on an individual level. - Triage new issues correctly
We have a simple standard: our tools must work flawlessly whenever our customers are presenting to their clients. Backend services, while clearly important, do not disrupt a presentation by our customers. This creates an easy and clear criteria for everyone in the company to decide when they should drop everything and focus on an issue. Too many response plans use ambiguous language. This can confuse internal teams resulting in the wrong response level. Keep it simple, make it clear.
