ThoughtWorks Technology Radar FAQ
Every six months or so, ThoughtWorks publishes it's Technology Radar. What started as an interesting experiment has turned into quite a notable publication, which gets lots of attention from our clients and other netizens.
As the radar has made more and more of a splash, we run into common questions about it - why it has the format it has and how we come up with it. So for the latest edition I thought it was time to come up with a FAQ.
photo: Evan Bottcher
Preparing a radar in Chennai, August 2012
What is the ThoughtWorks Technology Radar?
The radar is a document that sets out what we think is currently interesting in software development - the things that we think you should pay attention to and consider using in your projects. It's reflects the idiosyncratic opinion of a bunch of senior technologists based on our day-to-day work and experiences. While we think this is interesting, it should not be taken as a deep market analysis.
Who comes up with the radar?
The radar is written by the ThoughtWorks Technology Advisory Board, known as the TAB.
What is the TAB?
The TAB (Technology Advisory Board) is a group of twenty or so senior technologists at ThoughtWorks. The TAB meets roughly twice a year face-to-face and bi-weekly by phone. Our primary role is to be an advisory group for Rebecca Parsons, our CTO. The TAB acts as a broad body that can look at topics that affect technology and technologists at ThoughtWorks.
We build the radar at our face-to-face meetings. These meetings last about three 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 micro-service 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 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.
What's the structure of the radar?
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 how "close" these blips are - what stage in an adoption life-cycle we think they should be in.
Writing the January 2011 radar in Chicago
What are the quadrants?
The quadrants are a crude 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 which 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 persistance.
- Platforms are things that we build software on top of: mobile technologies like Android, virtual platforms like the JVM, or generic kinds of platforms like hybrid clouds
- Techniques include elements of a software development process, such as experience design; and ways of structuring software, such micro-services.
We don't make a big deal out of the quadrants - they are 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.
What are the rings?
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.
photo: Evan Bottcher
Our radar has four rings, which I'll describe starting from the middle.
- The Adopt Ring represents blips that we think you should be using now. 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 is 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 are happy to use trial blips now, but we realize that most readers will be more cautious than us.
- The Assess Ring are things that you should 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 are currently trialling, on our projects.
- The Hold Ring is for things that are getting attention in the industry, but we don't think are ready for use. Sometimes this is because we don't think they are mature enough yet, sometimes it means we think they are irredeemably flawed. We don't have an "avoid" ring, but we do throw things in the hold ring that we wish our clients 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 have 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 have not yet persuaded a client to try it out - and until we do that blip cannot pass into trial.
For the Adopt Ring we make use of Mason's Razor (since Mike Mason came up with it). Things only go in the Adopt Ring if we would laugh at you in the pub for not using them on an appropriate project.
What significance is there to the position of a blip inside its quadrant and ring?
We don't put much energy into deciding which quadrant a blip should go in, and none at all to its angular position within the quadrant. So the anglular coordinate of a blip is decided by the people doing the visual design and carries no semantic meaning.
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 are close to point of poking fun in pubs.
Why is <some-cool-technology> not on the radar?
There are various reasons why things are missing
- None of the TAB members have come across it.
- Some TABers 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
- 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.
Why do blips disappear between radars?
The radar represents things that are currently on our mind. Our default rule is that any blip only appears of the radar for two editions of the radar, after which it automatically fades - meaning it won't be shown on the next radar.
If the blip should fade, but we think it's worth keeping attention on, we may choose to "reblip" it - essentially keeping it around for another edition. When we reblip we must write something in the text of the radar to say why.
If we think a blip has moved into a new ring, that counts as a reblip.
photo: Evan Bottcher
Reviewing last edition's blips
When a blip appears on its second radar, we usually don't write about it again in the text, unless we have something new to say about it.
Sometimes we force-fade a blip on so it doesn't show on what would be its second radar. We do this when we think that blip has failed to hold its interest. Such a force-fade is usually due to lack of space and only indicates its relative interest level, it doesn't imply any change in our opinion of the value of the blip. If we try something and finds it doesn't live up to our hopes, then we move it to the hold ring.
How do blips change?
We've come up with various ways to show blips changing from one radar to another. Firstly we show new blips differently to blip 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 and 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.
What's the criteria for getting a blip?
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 anger, 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 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. We don't have a voting system, so far we've managed to sort it out by consensus. I suppose if it really came down to it, Rebecca would act as a final arbiter, although I'm sure she'd find a way to make it a group decision.
How do we build the radar?
The focus of building the radar is our bi-annual face-to-face meeting. Before the meeting TABbers are usually talking to plenty of people and thinking about what ought to be blipped. Non-TAB ThoughWorkers lobby for things they are interested in, although it's the TAB's radar, we seek out opinions from lots of sources, inside and outside ThoughtWorks.
At the face-to-face we spend several hours on the radar. Our main aim during the meeting is to decide what the blips are, and which rings they fall into. Since this is the most contentious part of the process, it's valuable to do this while we are together.
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 commonly in different rings. Once we have the candidates up on the board, we go through the long process of evaluating each blip. One at a time we take each blip and discuss whether we think it ought to be on the radar, and if so, where. This discussion is always enjoyable, there's lots of opinions and experiences round the room, but there's also a friendliness and mutual respect that makes the arguments much less grating than these kinds of discussions usually become.
photo: Evan Bottcher
Once we have the blips chosen and positioned, we then need to write the text for them. We do this using Mingle, so we can easily collaborate on the descriptions, each blip gets one champion who is responsible for writing it up. Most of the writing occurs after the meeting. The TAB has a coordinator who has the unenviable job of chasing us to get our blips written up.
At about the same time as we're doing the writing, a designer works on the graphic. We tell the designer what blips to show and their distance from the centre, but he decides on the angle within a quadrant.
Our coordinator pulls the text out of Mingle and puts together the various representations of the radar: currently we have pdfs, epub, MOBI, and HTML.
Can I build my own radar?
Yes, we encourage people to build their own radars. Indeed Neal has a popular conference talk on building your own radar. We think it's valuable for technology groups to get together and discuss what their radar should look like - it allows people to think about what they should be investigating and using.
You can do a radar on your own, for your personal aims. You can do one with your team or a wider company-wide effort. As well as the TAB radar we've seen other groups within ThoughtWorks come up with their own radars.
One question that came up as our radar got popular was whether we should try to copyright or trademark the term. We decided against, as we think that building a radar is a useful tool for anyone involved in our rapidly changing industry.
How can I get my product on the radar?
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.
There is no formal process, nor anyone to contact for demonstrations or the like. In particular we don't accept any payment for inclusion on the radar. (Although I'm told that getting a ThoughtWorker's attention through generosity in the pub is usually welcome.)
Why do so many ThoughtWorks open-source projects show up?
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.
Can I get someone to give a talk about the radar?
We often give talks about the radar. These are up to the individual speaker, most people like to focus on the blips they are 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 is familiar with it.
Neal also gives a talk on building your own radar.
What formats is the radar published in?
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 made an HTML version available, as we know many people prefer reading HTML to PDF. We have experimented with ebook versions, but aren't doing that for the May 2013 radar.
Why doesn't the reference list include all the things you mention?
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
This is so much stuff - how can I keep up?
Actually the purpose of the radar is to help us keep up. It's an inevitability of our profession that there is 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.
- 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 Asses 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.
- Stuff in the Hold Ring you can ignore, at least for the moment.
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.