The rationale is equally simple: I wouldn't take the time out of my day to send a bug report if it "worked for me." The problem could be any number of things: buggy code, incorrect instructions, browser incompatibilities, race conditions. Who knows?
You, as an engineer, should always always always assume that something is broken until proven otherwise. You must assume that there is a bug, until you can prove that there is not. Once you have ruled out a code error, then you can step into assuming the user is wrong. "OK, I did it the right way and was unable to reproduce it. Therefore, the user must have done something incorrectly."
Now you either try a bunch of different ways to accomplish it, or you go back to the user and say "I'm unable to reproduce this. Can you elaborate on the sequence of actions you took to cause this error?"
But what you should never, ever do is just dismiss the customer's complaint as invalid because you were unable to recreate it. If you can't recreate it, then you need to figure out why. Was the bug fixed by something else? Was the user mistaken? Does it only happen on Tuesdays at 3pm?
I'll say it again because it bears repeating: Remove the phrase "it works for me" from your vocabulary. From a reputation standpoint, it's bad news.
The customer isn't always right, and you don't have to blindly believe them, but customers don't report things unless something isn't working for them. Trust that.
Not only are developers a very expensive resource, they're generally not good at doing what you describe here. Nor are they usually well set up for it as their systems/devices are often tainted with development and debugging tools.
We can't make end users deliver bug reports that are detailed and reproducible, but (whenever possible) developers should only have to worry about reports that have those qualities.
Any organization that's grown beyond a couple founding engineers needs to have a layer of QA or Customer Support that's responsible for everything that you describe. It's a layer that not only pays for itself but also keeps both users and developers happy.
I wish I could remember who it was, but my Google-fu fails me today.
Edit: found it - http://www.codeofhonor.com/blog/whose-bug-is-this-anyway
Exactly. "It works on my machine" has over time become the easiest way to get a death glare out of me. To rehash the old quote, we are not shipping your machine!
Quite a few "bugs" are no fault of the developer/publisher. But learning where those issues are and letting your app alert/inform the user what's going on as they install to an invalid location or break their TEMP directory thinking they're protecting their machine or remove IE from Windows using a broken 3rd party utility or use an antivirus product that gets more wrong than right, etc... can help cut down on the bug reports, help the user from making 'mistakes' they shouldn't be allowed to make, and just make the whole process easier.
99999 out of 100000 yes. Sorry but most bug reports, even from QA departments are noise at best, nuisance at worst. And as I posted here before: I am close 40, have 15 years experience as a professional in this industry, I have seen it all and yes it gets harder for you to break through to me because I will presume you have no clue what you are doing because so many before you didn't. Sorry if you are the one special snowflake.
This is not to say my software is bug free, of course not! But unless you can describe the steps you made clearly and also have an expectation/happened instead , your bug report is useless. Again, this doesn't mean I expect reproducable bug reports but I need something solid to work with.
Your attitude, however, does match my experience: it is why people think software people are assholes. So be more mindful, please, from up there on your high, high horse. For yourself and for us as a profession and a craft.
It's almost always a good idea to understand what's behind the report. It's just that somebody in a different role should be doing most of that work.
If there's one thing I can't stand then it's people spewing fantasy numbers out of their ass without anything to back them up in order to give their argument some conjured up weight. You may well be right that a majority of bug reports are unhelpful, but please, if you need to use numbers, use ones you can back up with something.
Sorry to hear that OP's bug reports weren't taken seriously. Good tech support is a must for mission critical APIs.
At HelloSign we take great pride in our API and our tech support. Rather than outsource support or rely on less technical people, we have our developers directly support the API they built. So when you give our API a try, I encourage you to check in with one of our developers by visiting our public HipChat room (https://www.hipchat.com/gq4BMFKt1) or emailing them directly at apisupport@hellosign.com. And that's available to all customers no matter what pricing tier they’re on (including free).
Take a look at our API documentation here: https://www.hellosign.com/api/documentation
We’ve had a lot of API customers switch over to us from EchoSign’s API due to reliability issues. I have a lot of respect for EchoSign and their original CEO Jason Lemkin, but I do think the API was an afterthought for them. At HelloSign we think it’s the future and are committed to having the best-in-class API.
I also wanted to touch on your point about wanting to work with "a company with a soul". This is something I also look at when making buying decisions. I’ve found a company's Glassdoor reviews to be an effective barometer of how well a company treats its employees and, by extension, how its employees treat the customers. That’s one (imperfect) way to measure "soul".
Happy to answer any questions anyone on HN might have.
Counting on them to just "be nice" and do it for you anyway isn't really a valid option, nor something to base your objection on. If you don't like the service and aren't happy with the price then move on to someone else.
> ... the solution is to reinvent Adobe: to change the system from within. If Customer Success could talk directly to Product Engineering, then the bugs would get fixed, and the volume of complaints would go down, making everyone’s lives easier.
That process is enormously beneficial. I run an open source project, and spend a good chunk of my day answering low-level tech support questions. These are often "where is the ANY key". But a high percentage of them are people with real issues. I listen, fix the issues, and give feedback.
The result is enormous customer satisfaction. They get responses (and fixes) in 15 minutes. Their previous commercial solution would be 6 months, if they were lucky.
Shortening the feedback loop is a well-known engineering principle. But apparently not known enough in software companies. For systems with negative feedback, low latency is very positive.
More companies should have engineers deal with customer issues.
We did a case study here - if that helps: http://blog.hellosign.com/simplyinsured-leverages-esignature...
Highly recommended, and we've been with them for 2+ years!
Disclaimer - Never used the API, just like the service and its Box integration
One of the best parts of working with Hellosign is their amazing tech support team. They are incredibly responsive (and nice!), and have helped us troubleshoot issues on many occasions. We are on a first name basis with these guys, and would recommend working with them!
Then you're not paying your developers enough. A developer commands a much larger salary than tech support. You're either underpaying the developers, overpaying techs and calling them developers, or you're not being completely honest in an effort to pull in more customers.
I'd go with 3, but whichever it is, I don't trust anything you've just said.
1. Giving our clients the best possible technical support
2. Making our developers feel the pain (and joy!) of clients using what they built. I can't think of a better way to motivate developers to fix what's sub-optimal, share in the success of a job well done, and come up with new ideas to help our customers.
We're not alone in this strategy:
I've been using HelloFax since shortly after they launched, and it just works (TM). Highly recommended.
You can indeed say "it works for me" to the QA member, and it's their responsibility to identify the environment or series of steps that reliably produce a failure. From there on out, you can no longer say "it works for me" because it doesn't: you finally know how to make it fail and now it's your job to figure out why.
And like I said, nascent startups with just a few founding engineers are a necessary exception. But the QA or Customer Support hire should come very early! Too many organizations stall on that, and they waste tons of opportunity and productivity by doing so.
Or stop using the service.
Sharing the pain has benefits, but you're almost certainly paying more in lost productivity on both bugs and features than you're gaining in insight and sensitivity. As a small and stable company, you can probably afford the loss as you learn more about your market and as you prepare for more organizational complexity, but it will eventually inhibit your growth and burn out many of your developers.
Regarding flow, we don't have all of the developers doing support all of the time. We have one developer doing support at a time and rotate each week. This protects the rest of the team from having their flow I interrupted.
Putting the responsibility for tech support on your development team is how you increase your turnover rate.
Personally, I don't believe he's really doing that, I think it's just marketing.
I freelance and therefore I can be a jackass without direct monetary repercussions, perhaps that's why I don't view it that way.
Because I struggle to think of a lot of situations where I've been unable to replicate an issue a Client has reported where it hasn't turned into a miscommunication/misunderstanding of some sort.
I don't remember any specific instance where I had this misunderstanding, but a coworker had it happen and will never forget it.
I personally see it all the time, but I interact directly with my customers and it's always possible I'm terrible at communication. They'll say things like "X doesn't work on page Y", and It'll end up being a problem with a single link they clicked on because the data for it is such that it causes a problem (that sort of thing).
They don't know that's the issue either, you have to work with them on it.