ThoughtWorks Technology Radar v26

The latest, 26th, Tech Radar version from the folks at ThoughtWorks is now available.

As usual, it covers a range of technologies across 4 categories (Platforms, Techniques, Languages & Frameworks, Tools), rated on a scale of:

• Adopt: Strongly recommend
• Trial: Worth pursuing
• Assess: Worth understanding
• Hold: Proceed with caution

I’ve picked out some of the things I found most useful/interesting/relevant for me below, but I recommend checking it out in full at thoughtworks.com/radar.

Techniques

Four key metrics

(Adopt)
In my current company, we have been adopting the approaches advocated in the Accelerate book, so it was good to see the “Four key metrics” show up in the radar as adopt.

The metrics are:

• Change lead time,
• Deployment frequency,
• Mean time to restore (MTTR), and
• Change fail percentage.

The DORA/Accelerate research shows a clear link between high-delivery performance and these metrics; they provide a great leading indicator for how a delivery organization as a whole is doing.

The radar does caution against using the stability metrics (MTTR and change fail percentage) based purely on continuous delivery (CD) pipeline data though. Instead, they say, those metrics only make sense if they incorporate incidents that degrade service for the users.

They also discourage an over-focus on the 4 metrics at the individual team level and suggest team retrospectives as a fine alternative to identify improvements.

Single team remote wall 

Adopt 

A virtual wall for remote teams is recommended where story cards, tasks, status, and progress can be displayed, acting as an information radiator and hub for the team. This can replace physical walls that were popular in the office, and provide an “at a glance” view of a project. Updating it can be part of a daily ceremony. 

Definition of production readiness 

Trial 

A definition of production readiness (DPR) is a useful technique to support teams in assessing and preparing the operational readiness of new services. It provides guidance on what to think about before bringing a new service into production. While they may not define specific service-level objectives (SLOs) to fulfill (since those are hard to define one-size-fits-all), they remind teams what categories of SLOs to think of. Having a DPR can provide guidance, definite what organizational standards to comply with, and what documentation is required.

And speaking of documentation…

Documentation quadrants 

Trial 

Writing good documentation is an overlooked aspect of software development that is often left to the last minute and done in a haphazard way. Documentation quadrants can help ensure the right artifacts are being produced. This technique classifies artifacts along two axes:

• The nature of the information, practical or theoretical;
• The context in which the artifact is used, studying or working.

This defines four quadrants in which artifacts such as tutorials, how-to guides or reference pages can be placed and understood.

Thinking about and classifying in this way can

• Ensure that critical artifacts aren’t overlooked
• Guide the presentation of the content
• Help classify onboarding documentation

See more at documentation.divio.com.

Rethinking remote standups 

Trial 

The term standup originated from the idea of standing up during this daily sync meeting, with the goal of making it short.

But for remotely teams, consider experimenting with a longer meeting format, a “meandering team sync”. It’s about extending the time for the daily sync (to up to an hour). Activities can include

• Walkthrough of the team board (the core of a standup)
• More detailed clarification discussions
• Quick decisions
• Taking time to socialize

The technique is considered successful if it reduces the overall meeting load and improves team bonding. 

Team cognitive load 

Trial 

That system architecture mirrors team structures is not new news. See Conway’s Law, and the Inverse Conway Maneuver (use Conway’s Law to your advantage by organizing your teams to achieve your desired architecture). This Radar recommends measuring these team interactions using the Team Topologies author’s assessment to understand how easy or difficult it is to build, test and maintain services. By measuring team cognitive load, we can better identify how to change teams’ structure and evolve their interactions. 

Transitional architecture 

Trial 

A transitional architecture, much like scaffolding, is a useful practice used when replacing legacy systems. Transitional architectures will be removed or replaced later on, but play an important role in reducing risk and allowing a difficult problem to be broken into smaller steps. Thus they help with avoiding the trap of defaulting to a “big bang” legacy replacement approach. Care is needed to make sure the architectural “scaffolding” is eventually removed, lest it just become technical debt later on. 

Miscellaneous platform teams 

Hold 

Platform engineering product teams iare a good way for internal platform teams to operate, since they enable delivery teams to deploy and operate systems in a self-service manner, with reduced lead time and stack complexity. But platform teams need a clear and well-defined (internal) product. 

The specific technique being recommended against here is applying the “platform team” label to teams without clear outcomes, projects or customers. Such “miscellaneous platform teams” can struggle to deliver due to the high cognitive loads and poorly aligned priorities that result from working with a miscellaneous collection of unrelated systems.

These are not platform teams so much as a general support team for things that don’t fit or that are unwanted elsewhere.

Platforms

GitLab CI/CD 

Trial 

The trial recommendation here is that if you are using GitLab, consider using it for your CI/CD (continuous integration and continuous delivery) needs to. It can be especially useful when used with on-premise GitLab and self-hosted runners, as this combination gets around authorization headaches often caused by using a cloud-based solution.

Temporal 

Assess 

Temporal is a platform for developing long-running workflows, particularly for microservice architectures. It has an event-sourcing model for long-running workflows so they can survive process/machine crashes. Although we don’t recommend using distributed transactions in microservice architectures, if you do need to implement them or long-running Sagas, you may want to look at Temporal. 

Tools

Pactflow 

Trial 

The folks at ThoughtWorks have recommended Pact for contract testing for a while. They are now recommending Pactflow to improve usability, security and auditing on top of the open-source Pact Broker, to remove some of the overhead of managing contract testing at scale. 

Web Test Runner 

Trial 

Web Test Runner, a package within the Modern Web project, is a test runner for web applications. One of its advantages compared to existing test runners (like Jest, and Karma?) is that it runs tests in the browser (which it doesn’t seem Jest does, not sure about the others). It supports multiple browser launchers — including Puppeteer, Playwright, and Selenium — and uses Mocha by default for the test framework. The tests run fast, and you can open a browser window with devtools when debugging.

Excalidraw 

Assess 

Excalidraw is a simple but powerful online drawing tool that our teams enjoy using. Sometimes teams just need a quick picture instead of a formal diagram, for remote teams Excalidraw provides a quick way to create and share diagrams. Our teams also like the “lo-fi” look of the diagrams it can produce, which is reminiscent of the whiteboard diagrams they would have produced when co-located. By default, anyone who has the link can see the diagram but a paid-for version provides further authentication. 

Languages and Frameworks 

Java 17 

Assess 

Java 17 is the new long-term support (LTS) version of Java. While there are promising new features, such as the preview of pattern matching, it’s the switch to the new LTS process that should interest many organizations. Avoid the “too expensive to update” trap and assess new releases of Java as and when they become available.

Tags: radar, techradar, thoughtworks, thoughtworkstechradar