Developer Trends from Thoughtworks’ Technology Radar 27

Thoughtworks’ Technology Radar is a regular time to take a look at what experienced industry experts think might be the next wave of tools, practices, and technologies to consider or stop using.

I always look forward to adding many new “blips” to my list, or seeing which are growing in adoption since you last took a look.

Version 27 is out now, and it continues some trends that the radar has been following for a while, such as “platform as a service” or forms of group programming. This round-up is far from comprehensive, but just the blips that appealed to me or that, I thought, might appeal to you.

If any of them take your interest, or you have an opinion on anything I’ve featured, head over to your profile and let our readers know!

Mainstreaming of Machine Learning

It really does feel like that in the past 6 months or so, machine learning went from something that mostly only developers and data scientists interacted with to something that the public had awareness of.

There was announcement after announcement of another ML or AI-based tool that spat out some sort of media after you fed something into it, and we were swamped with thousands of strange-looking images and videos of celebrities.

This also means that developers interested in experimenting with ML also have a lot more resources available to them in the shape of data sets and frameworks to use those data sets.

Of relevance to experimenting developers is TinyML, a field of machine learning enabling a variety of always-on use-cases and targeting battery-operated devices.

Another is feature stores, a method for creating ML pipelines that might be more familiar to developers from other backgrounds.

This radar also covered ML-related tools for improving the developer experience of building and training models, for example, the practice of “federated machine learning” for aggregating model data across machines for processing or synthetic data for initial model testing.

Continuous Observability

Despite being a relatively new term, “observability” has rapidly grown from a loose collection of practices and standards for building a better picture of a running system to become a broader term to mean, well, to mean all sorts of things.

The latest area of the developer workflow to receive insights is one that I am surprised took so long, observability for continuous integration and delivery pipelines.

While CI and CD certainly bring benefits, processes frequently go wrong with very little insight into what until you try, try again.

Now, a handful of existing observability vendors and open-source projects are bringing tracing-style visualizations of continuous processes to hopefully help you debug quite what was going on.

Software Bill of Materials

As developers lean increasingly on semi-anonymous containers and packages for their work, those focused on security and legalities looked on and wondered, “do we trust this?”.

This concern has led to a rush to standardize and normalize (in enterprise, especially) a “software bill of materials”, often referred to by the comical acronym, SBOMs.

While, in theory, “anyone” can dig into an open-source project and see what its components are, this is generally easier said than done and isn’t possible with closed-source projects at all.

Recent high-profile vulnerabilities in software revealed how small dependencies can bring such large problems. While SBOMs could go a long way to help, I wonder how many companies will want to reveal their inner workings and be honest about them.

Sustainable Coding

This is a topic that I was inspired to cover myself after speaking with someone from Thoughtworks about their Carbon cloud footprint tool.

The tendency to endlessly throw new frameworks, tools, and cloud frameworks at a problem has led to many of us forgetting that all of these lines of code actually run somewhere on something.

And that leads to carbon emissions. Water motivated by altruistic reasons or financial, and an ecumenic downturn leads to cost savings, this is a topic more are talking and thinking about.

Closely related to the environmental cost of projects and their infrastructure, and an option I’ve seen used by production teams is infracost which estimates the cost impact of changes you make to Terraform definitions.

Responsibilities as Code

Any SaaS company defines service-level indicators (SLIs) and service-level objectives (SLOs) that their clients can expect.

However, how companies defined these have often been a bit haphazard and non-standard, and with so much else defined in codified pipelines, why not this fundamental component too?

Several Observability providers now offer this option and of course, a group of people started a standard, OpenSLO.

A No to Node

I dabble in JavaScript and TypeScript and have noticed a handful of emerging runtime alternatives to Node recently. I am not sure what is wrong with Node, aside from being fairly old now, to warrant alternatives, but I guess competition is good 🤷‍♂️?

Bun is one newer alternative that I tried a few months ago, and I’ll admit I wasn’t really sure what benefits it brought me, but it uses WebKit’s JavaScriptCore instead of Chrome’s V8 engine.

Again, variety isn’t a bad thing. Bun is written in Zig, which I had never heard of before, and it claims to be a “drop-in” C/C++ replacement.

Which leads nicely to…

C+++

If Zig, Rust, and other languages are anything to go by, numerous people feel that C++ needs a more modern replacement. Google has thrown another option into the list of contenders with Carbon.

The language is still in experimental stages but claims to be easier to understand and onboard with. Google has a tendency to spin up many experimental projects and then dump them again, so Thoughtworks’ suggestion is currently “wait and see”.