SDK - Should Your Team Build One?

Having spent most of my time at a company which had an internal SDK, it surprised me when I temporarily left to find that this is not the norm. In fact, in my experience, we're an extreme outlier. And yet, at the same time the other companies I've worked at or interviewed for all seem like prime candidates for an internal SDK. And this got me reflecting on what an SDK is and when it makes sense.

In the simplest sense, an SDK is really just any tools you use for development. And so, an internal SDK is typically a set of proprietary internal tools which help with specific development tasks. 

As for who should have a formalized internal SDK? Given the incredibly lax definition, I think that there are probably use cases for just about any team, but more generally I think that there are questions you can ask to figure out if it would be worth the effort investing in building one first.

Some of my questions are: do you have multiple teams and want to ensure some baseline level of consistency between them? Things like shared frameworks or best practices. Are there a lot of repeated elements of your process? If you think some important and/or common practices could be templated and reused. If you have multiple teams, do you also have redundant requirements? 

The first 2 questions are basically the same thing approached from 2 different angles. Basically, code generation tooling or standards enforcement. Most companies have a preferred or even mandatory stack as well as best practices or coding guidelines. Tooling and templates can help generate consistent code or enforce it. Tech debt rarely gets addressed and snowballs out of control beyond a certain threshold. Generating consistent code from the start and enforcing code standards earlier on helps to keep this in check. You can't always define rules such that they can be programmatically enforced and even common tasks can't necessarily be converted to any sort of template. But, where it can, it is almost always worth the effort if you have either a single large team, or multiple teams.

Honestly, if you have more than one team and you want consistency, you should probably be evaluating any possible options here.

And the last point is similar. If you have already identified things which could be templated or automated, and you know you'll do those things again, then very likely you should.

Another thing to consider beyond code generation or enforcement though is also utility classes and even APIs. When multiple teams are involved there can be duplicated efforts and these efforts end up being divergent in that the solutions evolve differently over time. This causes feature inconsistencies and code bloat. A shared API or set of utilities often means better code for all users. I will admit... this requires that shared classes be owned by better developers as newer or lower quality devs can easily cause the opposite here. 

And this brings me to my design philosophy for SDKs: Only restrict as far as you need to. 

If you don't trust your end users, the extreme end of the spectrum is controlling the whole process via a custom "language". IE -  Functionality is ONLY exposed EXPLICITLY through the SDK. And on the other end, you may automate some initial setup and allow for other assistive code generation, but once generated, it is just some industry standard languages and frameworks the devs are free. 

If you are too prescriptive you can create issues and/or more work for yourself when your limitations run up against business needs. Prescriptive tooling or code generation requires more tailor made documentation and support and is of intrinsically less value to the users. There isn't much in the way of transferable skills in these internal solutions and the more there is, the harder it is to onboard new devs as well.

If your tooling needs to be exposed to customers as well, you may need to lock it down further or even supply a separate experience. Both extremes and everything in between have valid use cases. For internal users though, limiting the constraints is key to success.