In January ThoughtWorks released the latest version of their Technology Radar in which they track what's interesting in the software development ecosystem. InfoQ spoke to Rebecca Parsons (CTO) about the latest results.
InfoQ: Firstly Thanks Rebecca for taking the time to talk about the Technology Radar. Could you briefly introduce yourself and the team behind the Radar.
The ThoughtWorks Technology Radar is produced by the Technology Advisory Board (TAB) of ThoughtWorks. The TAB is made up of technologists from all over the globe, representing India, Germany, the UK, South Africa, the US, Canada, Brazil, Australia and China. I started the TAB several years ago when I became the CTO to advise me on matters of importance to the ThoughtWorks technology community. The broad representation of the TAB brings a different perspective to questions as the technology landscape is different in the various countries in which ThoughtWorks does business. The Radar is an opinionated document, representing the opinions of myself and the TAB. While we crowd-source input to the Radar from the broader ThoughtWorks community, the TAB as a collective chooses what goes on it.
InfoQ: Why does ThoughtWorks produce (and share) the Technology Radar – surely this is a lot of effort for something made freely available.
We started the Radar as a way to track what was happening in the technology community and identifying areas we might want to participate in more fully. However, we've always been a big believer in transparency, participating in many conferences, writing blogs and books, and open sourcing many of our tools. Publishing the Radar just seemed the natural thing to do. I am gratified at how interest in the Radar continues to increase.
InfoQ: So what are the big trends in this Radar?
For each radar, we try to identify the themes. As the number of "blips" on the Radar have increased, these themes have become more important as a way of highlighting the broader trends we are seeing. The four themes this time include: 1) early warning systems and recovery in production, 2) the tension between privacy and big data, 3) the javascript ecosystem, and 4) blurring of the line between the physical and virtual worlds. The themes don't always indicate areas with the largest number of items; instead we focus on what we are seeing that's interesting.
InfoQ: The way the Radar is presented is interesting – you seem to be offering some very explicit advice in terms of the four levels the elements are plotted on – Adopt, Trial, Assess, Hold. What is the intent behind these categories?
When we started the Radar, we were most interested in what new things we should be watching. The Assess ring represents things to watch, while the Trial ring are items that we believe are ready for businesses to pilot. As we thought about publishing this externally, though, we thought it important to include our recommendations on what organizations should or shouldn't be doing. Our test for the Adopt ring is if we would "mock you in the pub" for not doing it. Since our target includes both early adopters and more conservative enterprises, there are some things that don't make it to adopt as quickly as some might expect. The Hold ring is a challenging one with two different purposes: things that aren't ready for prime time yet and things that aren't working out in practice. The latter category is far more common for the Hold ring, although I try to limit things in that ring to items that are widely used.
InfoQ: What sort of benefits could organizations anticipate if they take the advice about adopting the various elements at the centre of the Radar – what business problems could potentially be addressed?
The Radar is a point in time document, and we fade blips from the Radar if they've not moved for two Radars (or sooner if the Radar is too crowded). So, the Adopt ring on any given Radar doesn't include all the items that we believe should be standard practice. That said, the Adopt ring includes items that we believe are important to achieving software excellence.
InfoQ: Possibly looking beyond the Radar, what are some of the important technology related risks that organizations are facing today and what should they be doing to mitigate them?
It's hard to generalize, but I think organizations are not yet prepared for the pace of change that will be required in their technology offerings. For some, this is the result of being over-zealous and outsourcing too much of their technology capability. For others, this stems from a poor buy decision, investing in a package that now holds too much of what should be their business differentiators. For still others, this comes from having an architecture that is too coupled or is not adaptive enough. Enterprises that used to think they were in a different business now realize that they have to be, at some level, a technology company as well. There's a lot of work to be done to make these systems adaptive.
Community comments
dangerous if used by others to take direction from
by C Curl,
Re: dangerous if used by others to take direction from
by Faisal Waris,
One important factor missing from the radar
by Atle Haugan,
dangerous if used by others to take direction from
by C Curl,
Your message is awaiting moderation. Thank you for participating in the discussion.
Some of the categories seem to have rather vague ideas about how the different items have appeared and been classified. The criteria are vague ("to mock someone in the pub"). Its a highly subjective selection of brainstormed items. Although it seems to try and provide a polish to what Toughtworks want to push, like Gartner magic quadrants, its nowhere near that in terms of quality of input or description of rationale.
Looking at "Languages & Frameworks" the top choice in the Adopt category is Clojure. The rationale for the past few years has been "Nothing New. Move to Adopt", and before that a vague description lumping it in with other functional languages F# and Scala for assessment. This is a langage that has marginal support in the market, and low access to developers. The tool market is very immature. Its main claim to fame seems to be as a shiny new toy for people who think they've found a new angle to push Lisp to the masses.
I wonder how many projects Thoughtworks are running with Clojure? Or is it just Neal Ford pushing it? Are there any case studies on using Clojure for large projects and maintaining large codebases? How about those who tried and abandoned it? What were their thinking going in and coming out? Reminds me of the push for Ruby on Rails a few years back, before real-life experiences starting pouring in. A lack of critical introspection is to me a 'smell' which means it should never go into major adoption.
Re: dangerous if used by others to take direction from
by Faisal Waris,
Your message is awaiting moderation. Thank you for participating in the discussion.
While I think ThoughtWorks has lot of smart people, the radar is essentially a reflection of their personal opinion / experience and thus is not entirely scientific.
Case in point: F# jumped from #69 to #12 in the Toibe Index (see www.tiobe.com/index.php/content/paperinfo/tpci/...) yet it does not show up on the latest radar.
One important factor missing from the radar
by Atle Haugan,
Your message is awaiting moderation. Thank you for participating in the discussion.
The radar doesn't take into consideration an team or organisations ability (cost and time used) to adopt new technologies. And - perhaps more important - what it costs in time and money to get rid of old technologies. For technology-driven consulting companies working mainly on greenfield development projects, this is perfect. But for average teams in large companies, taking in new technologies have to be balanced with the same teams ability to get rid of the technologies they already have. I have seen many line-of-business applications where a considerable part of the technical debt come from different technologies that were introduced at some point in time, but over time have slowly faded into being a problem.
Some might read the technology radar as a smorgasbord of cool technologies to try out without considering the teams/company's technical heritage (and what it costs them). If they do, the decisions they make can be very expensive for their company.