UIs and SDKs

The sad realization I'm hitting is that most programming languages and Platforms are built to be throw-away. And I think a lot of this is unconscious.

To that point, the single hardest thing in my career has been trying to discover how to make the best UI possible for an SDK. There is virtually no documentation. If there are good examples out there I haven't seen them. And that hints at this broader problem. If you don't have an SDK and that SDK doesn't have an effective UI, then you've really only got an API. And APIs age poorly. People with skills but not enough patience will shift their efforts to writing something new. Hence the comment about being built as throw away.

The closest things we get are "SDKs" which are just cheap bolt-ons for IDEs.

An SDK needs a UI not because a UI or even an SDK is necessary. Let's face it, if you're the right/only solution then developers WILL learn the API and whatever tooling you supply. And some will even become experts. And at a certain level of proficiency the SDK may get in the way. But that isn't the point. You shouldn't be worried about those who have mastered the APIs. They are invested and/or interested if they came that far. 

It may be important to consider advanced users as well and enable the SDK to get out of the way more for them, but beyond that, they aren't the target audience.

Standing the test of time requires the ability to continually attract new developers and get them hooked. And this requires a toolset which allows them to get started and able to complete meaningful projects without the need to jump through hoops and spend months learning. And that may mean an SDK which advances as fast as, if not faster, than the core APIs it is helping with.

In my specific case, I don't need to worry much about adoption. There is no other option. It is an internal toolset for an internal Platform. But, that actually makes the problems more difficult to observe. I don't know which features are missing, or delivered in a poor manner. And that matters because failures in the SDK mean missed productivity. And successes in the SDK mean faster or more efficient development cycles.

And I think this is why .Net and .Net Core refuse to die. While Microsoft hasn't done much better, they have done better. The new project templates cover a number of meaningful scenarios. Tools like Blend and their emulators provide useful functionality to early adopters and pros all the same. And while the SDK is largely just a Visual Studio add-on it can get quite full featured in many cases.

But, it still caters to the advanced users who, ironically, are unlikely to use it. Developing a button with a form with dozens of options isn't appealing to either a novice or a pro. The novice is unlikely to find and deal with it and the pro has no use for it.

I think this is also a big reason why web frameworks are taking over. Telerik's Kendo is a great example of a fairly simple idea. Their documentation contains examples of many use cases, and each example can be launched into a live test environment where you can tweak the code and see the examples live. It is incredibly easy to take something like this, prototype out a real world example and then port it into your own code. It isn't an SDK as such. And yet, it does a better job of providing the kind of functionality that I think new developers expect than most supposed SDKs do.

This isn't the whole solution of course. But, if you've ever worked with an "SDK" in the past I suspect you will know what I mean when I say; there is a world of difference in terms of usability and discoverability.

And this isn't to try and stymie innovation and change. Frameworks should evolve and change and eventually be replaced. I simply think the lifecycle is too short today. Many existing frameworks could have lasted longer with more investment.  But, in the end, they weren't designed to foster that investment.