FAQ and more

The Radar is a document that sets out the changes that we think are currently interesting in software development — things in motion that we think you should pay attention to and consider using in your projects. It reflects the idiosyncratic opinion of a bunch of senior technologists and is based on our day-to-day work and experiences. While we think this is interesting, it shouldn’t be taken as a deep market analysis.

The Radar is written by the Thoughtworks Technology Advisory Board, known as the TAB.

The TAB is a group of 20 or so senior technologists at Thoughtworks. The TAB meets roughly twice a year face-to-face and bi-weekly by phone. Its primary role is to be an advisory group for Rebecca Parsons, Thoughtworks’ CTO. The TAB acts as a broad body that can look at topics that affect technology and technologists at Thoughtworks.

Rebecca Parsons (CTO) • Martin Fowler (Chief Scientist) • Bharani Subramaniam • Birgitta Böckeler • Brandon Byars • Camilla Falconi Crispim • Erik Doernenburg • Fausto de la Torre • Hao Xu • Ian Cartwright • James Lewis • Marisa Hoenig • Maya Ormaza • Mike Mason • Neal Ford • Pawan Shah • Scott Shaw • Selvakumar Natesan • Shangqi Liu • Sofia Tania • Vanya Seth

We build the Radar at our face-to-face meetings. These meetings last about four days, about a day of which consists of laying out the Radar. Other topics we might discuss include career paths for developers, reviewing the recruiting process for developers, how to grow our capability for new technologies, and our experiences with microservice architectures.

Rebecca chooses the membership of the TAB based on forming a group that can represent as wide a range as possible of technology leaders within Thoughtworks. The group has a global membership (which makes scheduling phone meetings a pain). Rebecca seeks advice from lots of people on who to have on the TAB, but the final choice is hers. The TAB shouldn't be seen as the top table of developers at Thoughtworks - there are plenty of important developers that aren't on it - but as a representative selection of the technology leadership.

The TAB's membership changes over time, so each Radar is chosen by a slightly different group of people to the prior one. Usually, we see two or three people change between meetings, although there is no formal term of service.

The Radar is all about tracking interesting things, which we refer to as blips. We organize the blips onto the Radar using two categorizing elements: the quadrants and the rings. The quadrants represent different kinds of blips. The rings indicate what stage in the adoption lifecycle we think they should be in.

A blip is a technology or technique that plays a role in software development. Blips are things that are ‘in motion’ — that is we find their position in the Radar is changing - usually indicating that we’re finding increasing confidence in them as they move through the rings.

The quadrants are a categorization of the type of blips:

• Programming Languages and Frameworks. This was just languages but we rolled frameworks into here with the October 2012 Radar.
• Tools. These can be components, such as databases, software development tools, such as versions control systems; or more generic categories of tools, such as the notion of polyglot persistence.
• Platforms. Things that we build software on top of such as mobile technologies like Android, virtual platforms like the JVM, or generic kinds of platforms like hybrid clouds.
• Techniques. These include elements of a software development process, such as experience design; and ways of structuring software, such as microservices.

We don't make a big deal out of the quadrants — they’re really just a way to break up the Radar into topic areas. We don't think it's important which quadrant a blip goes into, unlike the rings - which generate a lot of discussion.

The metaphor of a radar says that the closer a blip is to you, the sooner it will be on top of you. Like most metaphors, you can't take it too seriously, but there's an essential sense to it.

Our Radar has four rings, which we'll describe starting from the middle:

• The Adopt ring represents blips that we think you should seriously consider using. We don't say that you should use these for every project; any tool should only be used in an appropriate context. However we do think that a blip in the Adopt ring represents something where there's no doubt that it's proven and mature for use.
• The Trial ring is for blips that we think are ready for use, but not as completely proven as those in the Adopt ring. So for most organizations we think you should use these on a trial basis, to decide whether they should be part of your toolkit. Typically we've used trial blips in production, but we realize that readers are more cautious than us.
• The Assess ring are things to look at closely, but not necessarily trial yet - unless you think they would be a particularly good fit for you. Typically, blips in the Assess ring are things that we think are interesting and worth keeping an eye on.
• The Hold ring is for things that, even though they are accepted in the industry, we haven't had a good experience with. Therefore we are calling them out to warn you that you may run into trouble with them as well. Sometimes it means we think they're irredeemably flawed; or just being misused. We do place things in the Hold ring that we wish the industry wouldn't use.

Unlike the quadrants, we do have some quite passionate arguments about which ring a blip should go into. We don't tend to have angry arguments, but rings are what generate the most energetic discussions. Over the course of making the Radar we've come up with some useful rules of thumb to help us put things into rings.

We can only put blips into the Trial ring when we have experience of that blip on a real project. This can mean we sometimes look behind the technology curve, because we may like the look of a technology but haven't yet persuaded a client to try it out - and until we do that blip cannot pass into Trial.

For the Adopt ring, we only include items when we think it would be a poor and potentially irresponsible choice not to use them given the appropriate project context.

Given that many blips could be in a couple of different quadrants, we don't worry too much about which quadrant a blip ends up in, and pay no heed to its angular position within the quadrant.

In contrast, we do pay attention to the radial position. If we place a blip in the Trial ring but close to the Adopt ring, this means that we’re increasingly confident in its potential.

There are various reasons why things are missing:

• None of the TAB members have come across it.
• Some TAB members have looked at it but don't find it interesting enough.
• We put it on our initial list, but had to cull back the number of blips to let them fit on the Radar. This item was one of the victims — meaning we felt it was less important than the others.
• We've talked about it in a past Radar, and don't have anything new to say about it now. If a blip doesn't move, it fades from the Radar.
• We blipped something more generic, to talk about the wider concept. For example we didn't talk about specific NoSQL databases in our very first Radar edition, instead mentioning "non-relational databases". Later, we called out blips for specific NoSQL databases.

The Radar represents technologies that are currently on our mind. Given how fast technology is advancing, the default rule is that blips only appear on the Radar for one edition unless they move rings. However, members of the Thoughtworks Technology Advisory Board (TAB) can always make an argument to keep a blip, for example when something noteworthy has happened warranting a refresh of the writeup. Older blips remain searchable under the full A-Z index.

We think it’s important to keep older blips in the index for completeness and visibility, but please be aware that we’re not updating them. In some cases, Thoughtworks teams may continue to work with and recommend these technologies; in others, the advice could be outdated. If you’re looking at a blip from our archive, do keep this in mind.

We've come up with various ways to show blips changing from one Radar to another. Firstly, we show new blips differently to blips that have appeared before. We allow blips to move between rings. Blips may explode as a general category breaks out into different particular elements, or coalesce when we think we can treat several things as one.

Typically we do the splitting and combining when we see different parts of the broader blip should lie at different points in the rings.

Sometimes we move blips from one quadrant to another. This indicates our take on how to classify the blip has changed, since the quadrants aren't a big deal, we don't see such a change as important and thus it doesn't deserve any comment in the text.

Fundamentally, it boils down to one or more TAB members thinking it's important. We stress that it's a personal choice of the TAB - we aren't trying to build a Radar for the whole industry, this is our Radar. We publish our Radar because we've found that other people find our opinions interesting, but we don't believe we have some special authority. We do have a bias for technologies we've used in production, indeed that's a necessity to get into the Trial and Adopt rings.

The changing membership of the TAB affects the blipping. If a champion of a blip leaves the TAB, it's quite possible that the topics he or she is most interested in will get less attention in the future.

\We do try to limit how many blips we have on the Radar, so if we think it's getting too crowded we'll discuss which blips should stay and which won't fit, often with a vote to help focus the advice. The final decision-maker for placing blips is Rebecca Parsons.

No.

The Radar captures things that are moving - so we only blip things if we’re seeing a significant change in how we regard a technology across the rings. There are plenty of technologies that we like and use all the time that aren’t on the Radar because we think they’re settled and have long earned their place.

You'll find many of these technologies in past Radars, particularly those in the Adopt ring that have since faded. But even this is not a comprehensive list, since we’re always battling with space on the Radar.

We meet twice a year — ideally face-to-face — to discuss the Radar. Before the meeting members of the Thoughtworks Technology Advisory Board (TAB) usually talk to plenty of people and think about what ought to be blipped. Non-TAB Thoughtworkers lobby for things they’re interested in. Although it's the TAB's Radar, we seek opinions from lots of sources, inside and outside Thoughtworks.

At the meeting, the members of the TAB spend several hours on the Radar. Our main aim during the meeting is to decide which blips to include, which rings they fall into and what we should say about them.

We begin by putting candidate blips up on the wall, each placed in their suggested quadrant and ring. Often different people suggest the same blips, sometimes in different rings. Once we have the candidates up on the board, we go through the long process of evaluating each blip. We take each blip one at a time and discuss whether we think it ought to be on the Radar, and if so, where. This discussion is always enjoyable, there are lots of opinions and experiences around the room, but there's also a friendliness and mutual respect that makes the arguments much less grating than these kinds of discussions sometimes become.

Note: Be sure to check out this podcast episode to hear about how we adapted this process due to the COVID pandemic.

Once we have the blips chosen and placed, we then need to write the text for them. Each blip gets one champion who is responsible for writing it up, which typically happens after the meeting. The TAB has a product owner who has the unenviable job of chasing us to get our blips written up. Once written, they kick off an internal feedback process across Thoughtworks and work with various region representatives to begin translations. All the while, a designer works on the graphic.

Traditionally, the primary format for the Radar has been PDF, since it's a design-rich document we like to send to people. In recent Radars we've built an interactive HTML version to provide better ability to explore, search and link to blips.

Yes, we encourage people to build their own Radars, it a great way to visualize a tech strategy and we can help you get started. As an exercise, it encourages people to think about what technologies they should be investigating and helps them avoid the perils of living inside a technological bubble.

To get on the Radar you need to get the attention of TAB members, particularly in the context of our project work. If you get a TAB member excited, that can get to the Assess ring, but we need actual experience to progress further.

We don't have a formal process for external people to nominate tech, or to arrange demonstrations. But Thoughtworkers are always looking for ways to improve the software creation process and we're active members of numerous tech communities.

Primarily because we use them. Often, these projects are the result of a need we have in a client situation, frequently when we feel we're rebuilding the same thing again.

We regularly host a sneak peek webinar with two TAB members a few weeks before launching a new volume.

In addition to that, we often give talks about the Radar across the various Thoughtworks regions. The content is left up to the individual speaker; most people like to focus on the blips they're particularly interested in, although they'll happily answer questions about all the items. Usually Radar talks are given by a TAB member or two, perhaps with another Thoughtworker who's familiar with it.

If you're interested in getting someone to talk about the Radar, or for more information on these topics, contact your nearest Thoughtworks office.

We don't try to provide a comprehensive reference list, due to both time and space constraints. So we just include references to things that we think will be a little harder for people to track down, things that we find particularly compelling or those that present a different view.

Ajey Gore (2010-12) • Anne J Simmons (2015-16) • Badri Janakiraman (2011-17) • Brain Leke (2014-16) • Cassie Shum (2020-22) • Chris Stevenson (2010) • Claudia Melo (2013-15) • Cyndi Mitchell (2010-11) • Dave Elliman (2015-16) • David Rice (2010-11) • Evan Bottcher (2011-21) • Graham Brooks (2010-12) • Ian Robinson (2010-11) • James Fischer (2010-13) • Jiaxing Chen (2016) • Jeff Norris (2010-15) • Jim Webber (2010-11) • Jonny LeRoy (2014-20) • Ketan Padegaonkar (2017-19) • Lakshminarasimhan Sudarshan (2017-22) • Marco Valtas (2016-19) • Ni Wang (2018-20) • Nick Hines (2010-12) • Perla Villarreal (2020-22) • Pramod Sadalage (2010-12) • Rachel Laycock (2013-21) • Ronaldo Ferraz (2012-13) • Sam Newman (2012-16) • Samir Seth (2010-11) • Scott Conley (2010) • Srihari Srinivasan (2012-17) • Thiyagu Palanisamy (2012-16) • Wendy Istvanick (2010-12) • Zhamak Dehghani (2016-22)

Actually the purpose of the Radar is to help us keep up. It's an inevitability of our profession that there's constantly new stuff appearing, and we can't keep up with it all. You can look at the Radar as our opinion of how you should prioritize your investigations.

• Start by looking at the Adopt ring. Are you familiar (and using) all the blips here? If you're unfamiliar with a blip, look to see if it's relevant to what you do; if so you should be studying it now - and putting it into use as soon as you can. If an Adopt blip is relevant to your work and you're not using it, think hard about why.
• Pay careful attention to blips in the Hold Ring. We are pointing things that could be more harmful than helpful, depending on the context. If you are making use of it, you should reflect on why that is and whether it makes sense to start planning to move away from it. Educating others around you could be a good idea as well. You may find the BYOR (Build Your Own Radar) tool useful to get started on these discussions.
• Once you're familiar and starting to use everything in the Adopt ring, move to the Trial ring. Here, you want to look at each blip and consider which ones are relevant to you. Make sure you familiarize yourself with these topics - do some research on the web, get a couple of books, build a prototype with the more promising items. You could also start thinking about what it would take to trial them in your organization.
• The Assess ring is the last priority, which you can start investigating once you know about what's in the Trial ring. Because of your circumstances it may be more important to get to know something in this ring than something deeper in. Just because we haven't used it yet doesn't mean it's less important. But in terms of prioritizing your learning, the rings are a good way to go.

Of course this is just our opinion of your priorities. We don't expect everyone to agree with us, but at least it's a start.

Subscribe to the Technology Radar