Rebecca Parsons on the ThoughtWorks Technology Radar
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?
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.
dangerous if used by others to take direction from
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
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
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.
Doc List Oct 25, 2014