As in many development teams, there will always be questions like: “Why don’t we use technology X instead of technology Y? Technology Y is better for our case…”

Often candidates for a developer position will also ask during the interview what kind of technology we use. Since I was asked these questions from time to time, I sometimes had trouble spontaneously giving detailed answers. There will always be questions like this. But there is one issue that we as a team found even more difficult: How to keep our technology stack up to date while literally having a ton of new good languages and tools every day?

As developers at Content Garden, we always strive to incorporate and use the latest possible technologies in our development process. We needed a unified way to manage the specification of our technology stack that would answer the following questions:

• What technologies do we currently use?
• What should we consider in the future?
• Which technologies do we want to try out for our use cases and possibly use in the future?
• Which technologies that we already use we want to stop using?

For a long time, we had no specification that provided adequate answers to these questions – until we became familiar with the concept of the technology radar.

What is the technology radar?

According to our definition, the technology radar is a concept for defining and compiling the technologies that are used and that we want to use in our software development. The purpose of the technology radar is not only to get an overview of the technologies, but it also gives our team the opportunity to review our technology stack, test new technologies, adopt or abandon some of them within a certain period of time.

Okay… but how is the technology radar structured?

Our technology radar is categorized into the following elements:

• Blips
• Quadrants
• Rings

Blips

A blip is a technology or technique that plays a role in our software development context. Blips are components that are in motion – that is when we notice that their position in the radar changes – which usually indicates that we have increasing confidence in them as they move through the rings.

Quadrants

The quadrants are a categorization of the type of blips:

• Programming languages and Frameworks
• Tools: These can be components such as databases, software development tools such as version control systems or more general categories of tools.
• Platforms: Things we build software on. For example, mobile technologies like iOS, virtual platforms like the JVM or generic types 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, Domain-Driven Design (DDD) principles with Laravel or any other.

The quadrants are only one way to break the radar into thematic areas. We don’t think it matters in which quadrants a blip goes, unlike the rings – they trigger a lot of discussion.

Rings

The metaphor of a radar says that the closer a blip is, the faster it is above you. Like most metaphors, you can’t take it too seriously, but it does have an essential meaning.

Our radar has four rings, which I will describe from the centre:

• The Adopt ring represents blips that we think we should seriously consider using. We are not saying that we should use them for every project, as each tool should only be used in an appropriate context. However, we do believe that a blip in the Adopt ring represents something that has been tried and tested and is mature.
• The Trial ring is for blips that we consider ready for use, but which are not yet as tried and tested as those in the Adopt ring. We should use them on a trial basis to decide if they should be part of our toolkit.
• The Assess ring contains points that should be looked at closely, but not necessarily tried out yet. Unless we think that they would be a particularly good fit for us. Usually, 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 we had not good experience with, although they are accepted in the industry. That is why we mark them to warn others that they too could get into trouble with them. Sometimes this is because we believe they are not mature enough; sometimes it means that we believe they are irreparably flawed or simply being used incorrectly. We put things in the Hold ring that we wish would not be used by the industry.

Since we have adopted the concept and tools from ThoughtWorks Inc., I strongly recommend that you also visit their website, where explanations of the concept can be found in a detailed and more structured form.

What does our technology radar look like?

Techniques:

Platforms:

Tools:

Languages and frameworks:

What are the results of using a technology radar?

As we have only recently adopted this concept, we are still learning a lot and discovering new benefits. For the moment we can say that radar technology has brought us the following results:

• It gave the developers the opportunity to choose the technologies they wanted to use. This decision is no longer closely tied to one or two people (team leaders, etc.).
• We were able to clean up the outdated technologies and replace them with a new, better and more up-to-date ones.
• An exchange of knowledge takes place: By discussing and picking up the right technologies for a variety of needs, we get to know each other better and become aware of the skills everyone brings to the team.
• We have improved our recruitment process by increasing the transparency of the technologies we use. Our candidates appreciate it when we show them our technology radar because they can see what technologies we currently use, what we will not use and what we plan to use in the future!

Conclusion: Give it a try

The technology radar has taught us the structured use of technologies and tools. It has also given us the ability to follow a precise process when we want to introduce new technologies, rather than making ad hoc decisions on the spur of the moment. We definitely recommend trying this great concept because we believe it can help your team as much as it has helped ours. We look forward to using it in the coming years!