Code Generation

My favourite field of software development revolves around SDKs. And, in particular, code generation. But, after having worked extensively with internal tooling, I find myself perplexed that this isn't a broader phenomena.

I think there are rather substantial areas of computer science under-served here.

And, I think that there are 2 arguments against (though, this is admittedly speculation as I've rarely found anyone actually against this); SDKs already do enough, and that this is what 3rd party libraries are for.

My experience is that no, SDKs don't do nearly enough and chalking everything up to 3rd party libraries is both a liability and a solution which doesn't encapsulate all potential issues.

For instance, boiler-plate code. Some SDKs will generate some of this. And some could be automated by 3rd party libraries. But, most SDKs are just spitting out templates as a starting point and rarely expand that to domain specific topics. And, 3rd party modules can sometimes lend a hand here, but then, you often need to break the mould.

And, when your SDK pushes a 3rd party library and it needs to do something atypical you start hitting resistance. Firstly, companies tend to pass the buck directing you to doc or API for the 3rd party component. But, then you can't be surprised when people turn on your product. They may not have necessarily wanted that 3rd party dependency in the first place. And there is less YOU can do about the implementation. 

But, if you don't dump everything off to a 3rd party component you retain ownership. Yes, there is a cost to that. However, the purpose of code generation is to simplify the mundane or the complex. It is specifically to address these complicated issues. And being able to provide solutions to such issues is exactly what makes the field of value.

Generating code has a secondary benefit. It is easier to debug and adjust output when that output is code. This in turn allows teams to mature and take increasingly more burden off of the SDK over time. It also allows more thorough debugging which enables teams to address their own issues.

There is also always the issue of synchronizing releases. You want the code to stay up to date, but you can't force external parties to release on your schedule. So, you may be forced to release on their schedule if a critical vulnerability is found.

But, even with or without a push for 3rd party libraries (it is rather hard to avoid some external dependencies in any real world scale problem after all), there are still altogether too few SDKs or projects out there aiming to address this corner of the market.

To me, a competitive SDK doesn't JUST supply a starting point and APIs. It is a complete solution that will assist with common tasks and regenerating the foundation as the SDK evolves.

The best place to apply this is back end logic. Most back end frameworks have strict paradigms or patterns to follow if you want to succeed. And this makes for a very easy place to apply this sort of solution. But, it can also be used in UI projects as well. There are common elements and patterns followed in many UI applications which benefit from a code first approach.

The problem with this industry is that there are very few truly skilled and enthusiastic developers. Keeping developers and teams hooked on and moving forward within a platform or architecture requires tools to help those developers succeed.