Why, after a year with Adobe EchoSign, I’m taking my business elsewhere

Post by mreiland » Sat, May 02, 2015, 3:09 AM UTC

mark-r wrote: post #13

mreiland wrote: post #9

Earlier quoted context omitted.

it isn't that black and white. Many times it's simply a misunderstanding, the developer isn't actually testing the right thing. Saying "works on my machine" is the opening to a dialogue that involves "can you show me what you did?"

Sometimes it can be as simple as initiating something via keyboard vs. mouse.

Post by burnout1540 » Sat, May 02, 2015, 4:00 AM UTC

mreiland wrote: post #41

burnout1540 wrote: post #17

Co-founder and CTO of HelloSign here. 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…

> Rather than outsource support or rely on less technical people, we have our developers directly support the API they built. 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 w…

Post by burnout1540 » Sat, May 02, 2015, 5:33 AM UTC

mak4athp wrote: post #45

burnout1540 wrote: post #44

Earlier quoted context omitted.

Our approach may not be scalable (and may not fit into your worldview) but having our developers do API support for us serves two important purposes: 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 com…

I think your intuition is correct when you suggest that this approach isn't scalable. It runs counter to the concept of "flow", articulated in Peopleware[1] 30 years ago and confirmed many times since then. 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…

Post by DCoder » Sat, May 02, 2015, 5:53 AM UTC

mark-r wrote: post #43

mreiland wrote: post #42

Earlier quoted context omitted.

Are you implying it's a matter of getting your customers to use their brain? 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.

No, not at all! If you've been in the business long enough, you learn that people have different preferred ways of working. Some will use menus, some will use icons. Some will use keyboard shortcuts. Some will use drag-and-drop. If the bug description doesn't specify how they performed an action, and you assume your preferred way while they used another, you can easily be unable to replicate their problem. I don't re…

Post by mreiland » Sat, May 02, 2015, 6:57 AM UTC

mak4athp wrote: post #45

burnout1540 wrote: post #44

Earlier quoted context omitted.

Our approach may not be scalable (and may not fit into your worldview) but having our developers do API support for us serves two important purposes: 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 com…

I think your intuition is correct when you suggest that this approach isn't scalable. It runs counter to the concept of "flow", articulated in Peopleware[1] 30 years ago and confirmed many times since then. 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…