A Clojure Technology Radar

Every six months or so, we publish our Technology Radar. The radar sets out the changes that we think are currently interesting in software development, the things in motion that we think you should pay attention to and consider using in your projects. It reflects the opinion of our Technology Advisory Board, and is based on our day-to-day work and experiences.

We think it's valuable for technology groups to get together and discuss what their radar should look like. The radar metaphor allows people to think about what technologies they should be investigating and helps avoid the perils of living inside a technological bubble.

A language-specific radar recently came to our attention, and we wanted to interview Jon Pither, one of the creators, to understand more about their experiences of building their own radar.

What inspired you to create your own radar?

I used to work for Thoughtworks, so I’m very conscious of the Technology Radar. There seemed to be an opportunity to do something more specialised, something language related. We thought the Clojure community could benefit from something at a more granular level, that would be complementary to the Thoughtworks’ radar.

How did you get started?

We did wonder how you’d take it, but then we remembered Neal Ford’s blog post about building your own radar. You’re so open about how to build a radar, that pretty much inspired us.

Do you have an equivalent of the Technology Advisory Board at Juxt?

We’re a small developer-led software consultancy, so Malcolm, my co-founder, and I bootstrapped it. We mapped the Clojure base libraries to the radar and then we took it out to the wider community via our friends of Juxt google group. Our whole company is about tech, it was easy for me and Malcolm to blast out a first draft. The interesting bit was getting our community involved, that stirred up debate at a micro level.

What was the tech that you used to build it?

I started out using Brett Dargan’s javascript library to build it, but then went back to the drawing board. In the end it was built using dynamically marked up SVG in ClojureScript, and we'll open-source that when we get time. We built a database that the article is built from and the text that sits beneath the radar is derived from an algorithm. With hindsight, it might be quite onerous to refactor it to show the history of blips like the Thoughtworks radar does.

Yes! It gets complex to show that. Do you think radars need to show history? Can they be definitive or complete?

They need to be a living, breathing thing. We found it was great to talk about the direction that things can go. But a radar is not an objective opinion, it can never be definitive. It’s a snapshot of a point in time.

What feedback have you had?

The community feedback has been positive. We especially like that we have heard that it makes the journey less intimidating. Someone saying “this is what we use” is helpful for people. One of the things that inspired us to do it was that we are asked a lot about libraries, so it was good to get our views on that down.

Any detractors?

Not really. Some people said “I don’t like radars, but if I had to choose one it would be this.” The feedback was so positive, we have discussed if we should do a community driven one. That’s just at the idea stage though.

The Clojure community looks less fractured that other tech communities. How did this impact your radar?

There’s this energy in our community and people want to commit libraries that are actually useful. There's no culture of people building swathes of libraries and posting them on github. It tends to be complementary, people finding the best solution.

Is there a downside to that?

Well, there were a couple of libraries that it was hard to place. There’s a micro testing DSL, that basically spins up a new language to write tests. We had some people who weren’t fans, they said it had to be on hold, and we felt bad. We don’t want to hurt people’s feelings when they have poured their energy into building something. But for a radar to be useful and authentic, you have to put some things on hold.

You used the Thoughtworks taxonomy. What drawbacks did you find to using these?

The questions are just as relevant and useful at a language level. Next time though, we’d like to make it clear the direction that something is going in. How do you capture the bright stars, as well as the older ones? The classic problem with a radar, is about dropping things off, how do you manage the transition?

So when’s the next one coming out?

We are thinking of doing something in the summer. We’ve been keeping a note of new tools and libraries and people have been emailing us and suggesting things.

Check out the Clojure radar at https://juxt.pro/radar.html.