

Ask HN: Why Has SDK Become a Four-Letter Word for Developers? - werencole

At a developer conference last week, several app and game developers said, &quot;SDK has become a four letter word.&quot; That goes the same for API.<p>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?
======
forgettableuser
Lots 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
Check 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)

------
smt88
I 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
To 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
Lots 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) -

------
yunyeng
I 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.

