Edge case engineering

When we start a new design we target the mainstream: the ideal user who connects it up turns it on and gets what they expect. That's what's supposed to happen but it isn't always the case. That's when engineers have to consider edge cases. What happens if all doesn't go as expected? As we look at our upcoming server, Octave, it's the on-boarding edge cases that are the point of discussion these days. How do we make connecting Octave to the home network easy? And, what happens if the Octave server doesn't connect as expected? Perhaps someone has inadvertently configured their home router in a way that Octave isn't familiar with. We design for what we expect most people will have but we have to allow for the edge cases. And predicting the myriad of edge cases is challenging to say the least—like trying to predict how many ways someone can get something wrong. Fixing what's wrong is easy. Guessing what might go bad is a real challenge. Getting a new product to market can be a challenge, but not because of what most people assume: engineering it in the first place, getting it to sound right, passing the myriad of regulatory hurdles. No, those are the expected knowns that experienced manufacturers have been through multiple times. No, the most time-consuming engineering challenges turn out to be the ones least appreciated and hopefully never needed: the edge cases. In a perfect world, we'd never spend time on edge cases. Our world is hardly perfect.