First thoughts on developer gravity

At RedMonk we’ve been giving a fair bit of thought to fragmentation, and the overheads it creates, both cognitively for individual developers, and structurally in terms of technical debt. We don’t see any evidence of fragmentation decreasing any time soon, but I did have some thoughts this week while talking to a client about adoption of Artificial Intelligence/Machine Learning APIs (AI/ML) that I thought were worth noting. Because while fragmentation is a thing, it’s important to bear in mind that developers also show a marked tendency to stay where they are, with a toolset that is familiar and comfortable.While fragmentation is definitely an issue, so is lack of currency, which is another form of technical debt: sticking with old versions of things doesn’t help productivity.

By way of a framework for understanding developer choices, then, i wanted to note some factors that affect decision making.

Developer Gravity

“Truly the AWS Console is this generation’s Visual Studio” – Brian Leroux.

While Amazon Web Services (AWS) certainly doesn’t offer the best Developer Experience (DX) it has incredible Developer Gravity. It’s where developers live. New API and services pop up there at a clip, developers have an AWS account, and they know the AWS console as muscle memory. Talking of muscle memory, that’s definitely a factor in Developer Gravity, when it comes to code as craft – just think of vi vs Emacs. Once you’ve learned an editor you generally stay there. It become a point of pride. So within Developer Gravity there are various forms of stickiness, that mean something has to look pretty sweet to lead to escape velocity, and a new orbit. It may be that Developer Inertia is a better fit in terms of the metaphor, but for some reason gravity sounds better so I will stick with that. I always like The Data Gravity term, for example

Developer Experience

“Docker is the fastest time to developer dopamine” – Andrew Clay Shafer

This is the core usability of an API, SDK, service or tool. It is based on many different factors from documentation, to ease of use, notably time to deploy. A big part of the initial DX is about getting started – the “developer time to dopamine.” Of course, what is initially exciting about a platform may not be sustained as you go on using it. It’s the difference between a first date and relationship. The bright and shiny may not be as useful once you start using it in anger. It may seem easy to start with, then not. Deployment finds out initial ease of use.

A lot of developers talk about AWS Lambda in this way – creating the first one is super buttery, but then you start working with API Gateway. Of course frameworks mitigate rough edges, increasing Developer Gravity. In the case of Lambda, for example, Austen Collins created the Serverless framework.

The current hotness in terms of time to dopamine is Zeit.

Without good documentation, samples, and attentiveness to bug fixes though, DX is always going to be sub-optimal.

Perceptions of Developer Momentum

Developers are certainly not immune to the perception of momentum for environments they might target. Tensor Flow, for example, is seen as a hot technology. GitHub makes developer momentum more obvious than ever. 25k forks – sign me up! Developers want to adopt technologies than other developers find interesting. Herd mentality is a thing.

Pervasive Runtimes

While developers are interested in tracking technologies other developers are interested in, they also want to target pervasive runtimes and endpoints. While developers adopted objective-C initially partly for the chops, there is absolutely no question that IoS won because it was widely adopted, and offered an obvious model for revenue sharing in the Apple Store. Developers want to target platforms where they can make an impact.

This post is intended as a placeholder for further exploration, rather than my final word on the subject. Thus for example, DX should possibly be split into sub-headings. But really I just wanted to get down the concept of Developer Gravity, and see whether it has legs. Let me know.

 

disclosure: AWS and Docker are both clients.