Every six months, 20 or so senior technologists at the software consultancy Thoughtworks get together to compile the latest Technology Radar, a snapshot of the various tools, techniques, platforms, languages, and frameworks its consultants have encountered in the wild, each of which is represented by a blip on the radar.
Here are the four biggest themes from the April 2024 edition of the radar and why engineering leaders should care.
AI-assisted software development teams
What is it?
The rise of AI coding assistants – from dedicated tools like GitHub’s Copilot, to more general-purpose large language models (LLMs) like OpenAI’s GPT-4 – has been the defining technology trend of the last year. This was reflected by a third of all blips on the Technology Radar having something to do with AI.
While AI’s assistance with coding tasks has been its main application so far, the high levels of coverage on the radar shows that generative AI is already breaking out into other important aspects of the software development process.
Why should you care?
“What we’re really trying to do is look at every aspect of the software delivery process and find smarter ways of doing these things,” said Rebecca Parsons, Chief Technology Officer Emerita at Thoughtworks and a member of the advisory board responsible for the Technology Radar.
Engineering leaders know that coding only makes up a part of a developer’s job, so where AI can help with ideation, QA, root cause analysis, observability and other elements of the job will be of keen interest over the next year.
Architectural patterns for LLMs
What is it?
LLMs are already putting developers in a spin as they navigate which are the best choice for their workloads, how to think about portability, and the need to build effective guardrails.
With these choices comes a new set of architecture patterns and tooling to support common development contexts. Thoughtworks highlighted NeMo Guardrails – which streamlines the development of LLM governance policies – and Langfuse – which helps explain the steps taken by the model to reach an output – as two examples.
Why should you care?
Many engineering leaders will have to go back to school when it comes to evaluating these emerging patterns and tooling options. “What we have now with these LLMs is, for most enterprises, a fundamentally different kind of entity,” Parsons said.
Engineering managers will have a growing list of questions to answer if they want to take advantage of LLMs. “What does the presence of this beast in my technology estate imply? How is it going to be used? What are the kinds of guardrails that we want to put around it?” Parsons asks. Policies and guardrails will also need to be established around personal information, anonymization, and intellectual property.
“There are all kinds of questions that come down to getting the most out of this without opening myself up to risks that I don’t necessarily understand,” Parsons said.
Open-ish source
What is it?
Open-source software is in the midst of an existential crisis, as cloud providers continue to threaten established business models and frazzled unpaid maintainers feel the pressure of propping up vital infrastructure. Engineering managers will need to be aware of these changes and how they are impacting the software they are likely dependent on.
There are several examples of prominent technologies switching to more commercial licensing terms in recent years, largely to fend off competition from cloud providers – Redis, Elastic, Docker, and Hashicorp, to name just a few. These choices leave customers with a difficult decision: pay up for the new commercial version, find an alternative option, or wait for a forked open-source project to emerge, as has been the case with the OpenTofu fork of Terraform and now Valkey from Redis.
“We find it problematic when core functionality of a widely used tool is suddenly put behind a paywall, especially when an ecosystem has developed around the tool,” the Thoughtworks technology advisory board concluded.
Why should you care?
Engineering managers need to be more vigilant than ever about which open-source software is in their ecosystem and the cascading dependencies that a licensing change could impact.
Parsons is seeing many leaders caught in “a cycle of the rug being pulled out from under them, and maybe they’ll put up with that for a little while, but eventually somebody else is going to come up with an alternative.”
That being said, the Log4j vulnerability in 2021 highlighted that “engineering leaders are not going to expose themselves in that same way. I don’t know how this is going to play out, but we’re certainly seeing a lot of activity around it,” she said.
Continuous integration vs PRs
What is it?
Thoughtworks and its chief scientist and advisory board member Martin Fowler are vocal proponents of continuous integration (CI), which he defines as “a software development practice where each member of a team merges their changes into a codebase together with their colleagues changes at least daily.”
Instead of relying on pull requests (PRs) and review cycles, each change is “verified by an automated build (including test) to detect integration errors as quickly as possible.” Why are we telling you this? Because the humble pull request has proved a stubborn element of the software delivery process.
“Many of our teams are compelled to ignore the CI part of CI/CD because they find themselves in situations where pull requests are mandated,” the Thoughtworks advisory board found.
While pull requests have their place in massively distributed codebases, in smaller teams it’s probably an unnecessary comfort blanket. There is a growing ecosystem of tools aiming to alleviate this friction, such as gitStream and GitHub merge queue, as well as techniques like stacked diffs.
Why should you care?
Parsons admits that Thoughtworks is “losing the intellectual battle” between PRs and what they see as true CI, but can engineering managers have their cake and eat it?
“There are more and more instances where people are trying to fix the problems that are introduced with the pull request model, to bring it closer to true continuous integration,” she said. “Our position is that this shows a desire to cling to the pull request model, while doing everything possible to make it look more like trunk-based development, without actually giving up the pull request.”
In a world where teams are more restricted than ever, it may be a good time to revisit these delivery processes, and maybe even think about letting go of the PR.
Final thoughts
It feels like a particularly fraught moment right now for engineering managers, but it’s important to remember that this is an industry built on constant change. Stay curious, keep an eye on the Technology Radar, and don’t bury your head in the sand.
Cautiously embracing AI, building contingency plans for your open-source dependencies, and evaluating if you really need all those PRs in your software delivery process are all worthwhile exercises as we swing into the middle of another year.
