Lessons from Failed DocuSign Integration
profsmallpine.com
Lessons from Failed DocuSign Integration
1–10 of 85 posts
Re: Lessons from Failed DocuSign Integration
#2> we’ve tried to build as much as we can as to skip dependencies, I’ve spent enough time in rails to appreciate debugging owned code - an argument for another time...
Okay, I'll bite. I have no experience in RoR, but does this line suggest that RoR encourages NIH?
This line feels like that scene in a horror movie, right at the beginning, when the camera lingers a little too long on the janitor's face as he cracks a smile that's wider than it should be.
Red flags:
* NIH (mentioned above)
* Using Go in production (more specifically, complaining about the lack of support for Go in production -- you should have known what you were getting into)
* Announcing a hacked-together MVP to the whole company
* Escalated to a VP for a technical issue
* Not using the company's recommended workflow, instead building your own
There's no way that the inability for the author to deploy DocuSign, an API that hundreds of companies successfully use, is on DocuSign.
Also, an maybe this is just a cynical view, but when you start your cautionary tale with a literal, "It all started when I was 11", it's kind of hard to relate.
Re: Lessons from Failed DocuSign Integration
#3The article was a bit meandering (bit of a bildungsroman), but good to know to avoid docusign apis. Might have been able to find out how much it sucked just by googling more "docusign alternatives" or "docusign api sucks" =D
Re: Lessons from Failed DocuSign Integration
#4I've done a docusign implementation, and I don't really agree with them. Their API is fine honestly, I think their documentation could be better and some things are named awkwardly. But the implementation really isn't hard, my only real complaint is that when we did it they pushes the DocuSign connect service really hard, which honestly was kind of a waste and didn't live up to many of their promises, but that's normal b2b upselling. It's a normal API, and definitely not as bad as this person makes it seem.
Re: Lessons from Failed DocuSign Integration
#5> we’ve tried to build as much as we can as to skip dependencies, I’ve spent enough time in rails to appreciate debugging owned code - an argument for another time... Okay, I'll bite. I have no experience in RoR, but does this line suggest that RoR encourages NIH? This line feels like that scene in a horror movie, right at the beginning, when the camera lingers a little too long on the janitor's face as he cracks a s…
Absolutely not on the RoR encouraging NIH side - there's a huge ecosystem of libraries to handle most of the day to day stuff, and because of the way Ruby works its really easy to stub out things like 3rd party APIs for test suites. If someone on my team tried to argue that they should implement the API client themselves rather than using the provider's implementation without a really good reason I'd shut them down.
Re: Lessons from Failed DocuSign Integration
#6The author seems to have buried the lead here:
"Someone on the team noticed that if you refresh the page, you get logged in as the user that was making the API request"
And that is how the implementation works for many of Docusign's customers as a 'feature'. If that's true, that would seem like a potentially exploitable security hole. However, I'd have to question if that had something to do with the particular implementation, otherwise I'd expect more focus on the security repercussions.
Re: Lessons from Failed DocuSign Integration
#7Looking at the API description (very detailed BTW) https://developers.docusign.com/esign-rest-api/guides/authen... , it does look like they used a wrong flow for the use-case, and then invented some shortcuts to make it work (which understandably did not work out well).
It does look like onboarding failure, but there is so much you can do to steer the customers towards the right path. I am not completely convinced that this was Docusign's fault.
Re: Lessons from Failed DocuSign Integration
#8> we’ve tried to build as much as we can as to skip dependencies, I’ve spent enough time in rails to appreciate debugging owned code - an argument for another time... Okay, I'll bite. I have no experience in RoR, but does this line suggest that RoR encourages NIH? This line feels like that scene in a horror movie, right at the beginning, when the camera lingers a little too long on the janitor's face as he cracks a s…
What is NIH?
Re: Lessons from Failed DocuSign Integration
#9I've done a docusign implementation, and I don't really agree with them. Their API is fine honestly, I think their documentation could be better and some things are named awkwardly. But the implementation really isn't hard, my only real complaint is that when we did it they pushes the DocuSign connect service really hard, which honestly was kind of a waste and didn't live up to many of their promises, but that's norm…
Whether an API is "good" or "bad" often is dependent on the requirements of the calling client.
At the beginning of projects when client requirements are unclear, it is often hard to determine whether a supporting API/library truly meets your needs.
Re: Lessons from Failed DocuSign Integration
#10> we’ve tried to build as much as we can as to skip dependencies, I’ve spent enough time in rails to appreciate debugging owned code - an argument for another time... Okay, I'll bite. I have no experience in RoR, but does this line suggest that RoR encourages NIH? This line feels like that scene in a horror movie, right at the beginning, when the camera lingers a little too long on the janitor's face as he cracks a s…
What is NIH?
Not Invented Here, a term normally used to describe the thinking that instead of using libraries we should write all our own code.