4 ms·
Ask HN: Why Has SDK Become a Four-Letter Word for Developers?
At a developer conference last week, several app and game developers said, "SDK has become a four letter word." That goes the same for API.
I have a general sense as to why this is, but I am curious to hear it from the community. Why are SDKs and APIs a dreaded aspect of the development cycle?
- smt88 11y agoI love SDKs and APIs. "SDK" means to me that someone else has done a bunch of work for me. A good example of the AWS SDK, which lets me very quickly integrate S3 uploads into anything I'm working on. "API" means that I can use someone else's data and mash it up with my own (or even another person's data), and that's really exciting! In summary: no idea why those people said that.
- werencole 11y agoTo elaborate on my general sense of why the developers said that: there are now dozens of pertinent SDKs that developers need to stitch in to their apps. Same with APIs. They take time to implement, can effect the performance of an app and sometimes don't really work all that well. An app developer could reasonably have dozens of third-party SDKs in an app. Say, Flurry, Applause Analytics, Google Analytics, Maps, Facebook, Twitter and so forth. Same with various APIs. I remember one developer I was talking to on Twitter last year was so fed up with third-party SDKs that he basically swore them off except for the most essential ones. He was having a hard time stitching someone else's code into his app and the implementation was just wonky.
- benologist 11y agoLots of work, may require invasive permissions, may run afoul of app store rules etc, may be a pain in the ass integrating with whatever non-native approach you're building an app with, and potentially weeks to get any change live. The people at FGL.com are working on a promising solution to this - http://enhance.fgl.com http://enhance.fgl.com -
- forgettableuser 11y agoLots of reasons: - Software bloat leads to slow download times and slow launch times and more RAM usage - Abstraction layers often get out of control and sacrifice lots of performance and lead to software bloat - Often you start with and SDK thinking it will solve your problem, but it turns out it doesn't solve your exact casem which means you end up spending lots of time fighting the SDK which leads to a mess+abstrction+bloat. Many times you might have been better off writing it from scratch. - Dependency hell which brings in the bloat+abstraction problems. Plus now you now have extra environment and deployment headaches to make sure everybody involved has the correct dependency chain and correct versions of everything. - Build system hell: Once you have dependency hell, you often bring in build system hell to manage everything - SDKs (Frameworks) take control of everything: Often frameworks impose lots of rules and conventions that leak into everything else you do. This means following their design patterns, subclassing from their classes, etc. Their stuff may not fit well with your own stuff. Also, this often deeply entangles your stuff with their stuff so it is hard to remove later. - Fighting between SDKs: Lots of SDKs try take over the world. If you use multiple SDKs, they may fight. - Lack of understanding: People too eager to use SDKs often lack the understanding of how it works. To fix bugs, to fix performance problems, to extend features, means you must ultimately understand it, but often this comes too late in the process. And you discover that for all these things will require massive changes to the framework or a complete rewrite. You would have been better off writing it yourself in the first place or picking some other SDK that you understood better.
- forgettableuser 11y agoCheck out the Handmade Manifesto for a better feeling of where people like these are coming from. https://news.ycombinator.com/item?id=10095104 https://news.ycombinator.com/item?id=10095104
- yunyeng 11y agoI believe myself this development in APIs is just tip of the iceberg. If the software development goes like this, everything will become huge, and hard to scale, and will need lots of engineering resources.