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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.