From the Trenches: Technology Radar Volume #17
Introduction
The title of this post is influenced by a 2012 post of mine which went into detail discussing a suite of commercial products that I had used on a project at that time, with the tagline "from the trenches" to emphasize that my writing was from personal development experience. Regardless of the degree to which a software product is commercial or open source, products can tend to claim at least some aspects of functionality that either do not work, or do not work as intended or evangelized. And while I have been an open source advocate for quite some time, some community advice can be misleading or simply incorrect.
ThoughtWorks claims that its writers share their opinions from experience, but the "Technology Radar" reports presented by the firm offer very little discussion. This post is an attempt to address one entry from each of its recent November 2017 radar quadrants: "languages & frameworks", "platforms", "techniques", and "tools". The purpose of this post is not to delve into detailed definitions of each entry, but to consider each entry from the perspective of my experiences and how ThoughtWorks chose to categorize.
Background
It is not uncommon to hear developers bemoan use of the term "architect" to describe themselves and what they do for a living, to the extent that "senior developer" now often refers to individuals who are actually architects, but do not wish to be recognized as such because it can imply that they are no longer hands-on from a development perspective.
However unfortunate this situation, one of the problems with using the term "developer" exclusive of "architect" is that it tends to imply that what one does is limited to programming or some interpretation of DevOps. In other words, relying on others to be concerned about the decisions feeding these work activities, whether these be interpretations of what users want, or what technologies to use.
At some point earlier in my career, some of my colleagues and I started referring to ourselves as "practical architects", a term which is intended to imply that the ivory tower of architecture has no place in our work efforts: we are practical because we can not only relate our decisions to the practicality of how these are to be implemented, but can also perform the implementation itself.
The discussion as to whether programming is necessary to make decisions or to show others how they might make use of chosen languages, frameworks, tooling, and software development techniques is arguably not an empty argument. One of the big questions here is the degree to which one can be effective without actually touching and feeling that which is being advocated or discouraged.
Over the past few years, I have been following the Technology Radar reports sporadically published by ThoughtWorks that are intended to categorize the aforementioned areas of technology in a manner which seeks to advocate the degree to which something should be used, including whether something should not be adopted at all. This take is a bit different than other technology reports with which technologists might be familiar.
For example, Gartner uses what are called "Magic Quadrants" to categorize, but what is being categorized by these reports are the vendors of products, not the products themselves, although it can be argued that many vendors are so closely tied to their flagship offerings that how they are categorized has a great affect on their product lines.
One of Gartner's competitors is Forrester Research, which publishes its reports called "The Forrester Wave". Forrester also indicates that what it evaluates are product vendors, but closely follows up on this objective by stating that it compares products and services by these vendors within specific markets, and it does not take long to see that it explicitly lists the products representing each vendor evaluation.
Gartner also publishes another report called a "Hype Cycle", which is intended to depict the maturity of a technology through phases that the firm refers to as "Technology Trigger", "Peak of Inflated Expectations", "Trough of Disillusionment", "Slope of Enlightenment", and "Plateau of Productivity". But be aware that each report is a snapshot in time, and technologies should not be expected to traverse multiple phases.
In this sense, Technology Radar reports are probably most similar to the Hype Cycle reports, because ThoughtWorks refers to occurrences of technologies and techniques as "blips" which come and go. However, while ThoughtWorks rightly cautions use of its reports in isolation just like the other firms, it also mentions that reports are not based on deep market analyses.
Placement in the "adopt" ring indicates that a blip is proven and mature, and ready to be used in the appropriate context. On the opposite end, the "hold" ring indicates that a blip is either not mature enough to be placed in another category, or should be avoided. Between these two extremes are the "assess" and "trial" rings, which are intended to categorize blips as being less proven or more risky than if placed in "adopt".
In my view, the categories that ThoughtWorks provides in its reports can be a bit esoteric, but if one views these as simply suggested levels of adoption, it can bring some simplicity to what is presented. Just keep in mind that the included blips are limited to the technologies and techniques run across or used by ThoughtWorks development teams. Despite this element being a limitation, it is also what brings practicality relative to other reports out there.
Just to reiterate: no report should be used in isolation. To be practical means to determine level of adoption within a specific context, which means good fit with respect to a development team and the larger organization within which a development team exists. A development team should not adopt something by only considering its own needs: the needs of other stakeholders also need to be taken into account.
Let's take a look at the blips I've chosen from each quadrant.