Investing in Software Developer Kits (SDKs)
It’s early in 2015 and if you’ve ever worked in Product Management you know what that means: we are starting to execute our big, audacious 2015 product plans. In our Q4 planning cycle we looked at everything we could possibly do and tried to prioritize for the next year.
At Constant Contact, we came into our 2015 planning session with a single goal: Great Product. One of our Core Values is “Customer First. Always,” so when we looked at our goal from a Product Management standpoint it became clear that the only way we could really deliver is by creating a great product that our customers love and find valuable.
We ranked and rated our API platform across many dimensions and realized that our Software Developer Kits (SDKs) are one of the areas where we can have a huge impact on our developer experience.
Our SDKs, available on GitHub, are the primary way the majority of our developer audience interacts with our API. As we looked at this, we realized that most of our developers don’t see the hard work we put into our API and API documentation; they actually see the work we put into our SDKs and SDK documentation.
Focusing on our SDKs and related documentation is an opportunity for us to provide better tools and solutions that let our developers get their work done faster and easier.
2015 SDK Plans
We examined all of our SDKs in detail from the perspective of our developers. It was clear that they were not great products and that we had some work to do in order to make them great. We looked around at leading API platforms to find out how they developed and supported their SDKs. We also took feedback from our developers who use our SDKs regularly and spoke at length with our API Support team.
We distilled all this data and feedback into the following set of 2015 SDK initiatives that we plan to deliver to our developers:
Language Idiomatic SDKs.
Not all coding languages are the same. In fact, the core languages that developers use to integrate to Constant Contact (PHP, .Net, Java and Ruby) are all very different. Our SDKs should work and feel like they are designed and built for each individual language. In order to achieve this, we are having experts in each of these languages redesign and refactor our SDKs to make them feel more natural to developers.
Use Common Standards and Frameworks
Every language has core web development standards and frameworks that developers use. Our goal is to build out our SDKs to leverage as many of these core standards and frameworks as we can, in order to shorten learning curves, speed up development, and increase developer confidence
Highly Dependable and Tested
The best SDKs we found included built-in unit tests and were very well maintained. Although we have some unit testing in our PHP and Ruby SDKs, it is not nearly enough. Our goal is to have 100% unit test coverage in our SDKs by the end of the year.
Automated Builds and Deploys to Central Code Repos –
While having our source code available on Github has been great, we’ve had numerous requests from our developer community to host our built SDKs in central code repos such as Ruby Gems. This allows developers to quickly pull down SDKs into their dev environment and start coding. We’re in the process of setting up automated builds and deploys to these repos so that developers can get their code from where they are already working.
2015 Sneak Peak
We’re planning a lot of enhancements, bug fixes and new features in 2015. Our focus will always be on Great Product and Great Developer Experience. Here’s a sneak peak at some of the items we’re planning on delivering in 2015:
- Enhanced Contact Management – enhancing our API suite to provide full access to all of our new Contact Management UI features
- Documentation Updates – increasing our documentation accuracy through automation, adding more code samples, examples, best practices and more guides are just some of the areas we’re looking at tackling this year
- Developer Onboarding Experience – we’re working on simplifying our onboarding experience for new developers
What do you think about SDKs for APIs? What enhancements would you like to see happen to the existing Constant Contact SDKs? Share them with us in the comments section.