Why Adopt Matters
Each new edition of the Thoughtworks Technology Radar is the result of extensive internal discussion. Our Technology Advisory Board (TAB) debates the merits of scores of potential blips. The group that inevitably attract much attention are those that are in the Adopt ring—particularly those that have newly moved into Adopt.The number of blips in Adopt is always relatively small. That’s because we set the bar pretty high. Adopt is our way of showing that within a carefully prescribed use case, we think there’s no better choice of tool, platform, technique or framework.
While being in Adopt means we think there’s no better choice, there’s still plenty of room for disagreement about whether a blip really should be there. For instance, there many items in the Trial ring that are ready to use in the enterprise—but if there’s any uncertainty about their use case, they won’t get into Adopt. Indeed, if we think enterprises are simply not ready, blips that have stayed too long in Trial will get faded.
Read on to get a deeper insight into the newest entrants into the Adopt ring.
Python Comes of Age
There may be a few eyebrows raised to see Python 3 being placed in Adopt—not least from those wondering why it’s taken so long. After all, Python 3 was first released in 2008; we placed it into the Assess ring in 2014, so why move it now?
It’s fair to say that there were many Thoughtworkers who think we’ve been conservative in our assessment of Python 3. And it’s been been hugely popular in academia for years.
The main obstacle to Python 3 migration has been the lack of support from some critical libraries. For instance, the mySQL driver for Python 3 took far longer than we’d have liked to see. Today, the lack of libraries can still be a project killer, but the number of libraries that are not Python compatible is negligible.
Added to this, our experience using Python 3 in domains such as machine learning and web application development shows that both the language and most of its supporting libraries have matured sufficiently.
So does the Adopt recommendation for Python 3 mean we should also have put Python 2 in Hold? Python 2 is certainly not immature nor irredeemably flawed. And official support for Python 2 from the core developers is promised until 2020, but it's likely many vendors such as Google, RedHat, Continuum Analytic, will continue supporting it well beyond that, at least for security fixes. So for now, we wouldn't put Python 2 in Hold, but we'd definitely recommend version 3 for new projects.
On the Fastlane in Mobile App Development
Mobile app development might be hot, but it doesn’t make the building, testing, documenting and provisioning any more exciting. Thankfully, there are tools like fastlane to automate some of the release process. That’s important when developing for mobile, where iOS and Android have different approaches.Our experience in using fastlane has proven it delivers good results, especially when it comes to continuous delivery tasks because it abstracts common problems, such as distribution to the iOS and Android appstores.
The results we’ve achieved with fastlane have given us great confidence. It was first placed in Trial as recently as November 2016. We’re naturally cautious when it comes to moving blips into Adopt rapidly, but the results we’ve seen with fastlane have given us confidence that it’s ready.
We’re naturally cautious when it comes to moving blips into Adopt rapidly.
Even with the Adopt recommendation, there are limits to what you can expect from fastlane. You still need to configure certificates to distribute apps, you need a CD tool, and you still need to configure boxes where the code is compiled, tested. After all, there are no silver bullets when it comes to development.
ReactiveX’s Surprising Entry
Most blips will have featured on a few Radars before moving into Adopt. So it may surprise you to see ReactiveX in the Adopt ring. It’s the first time this blip has been on the Radar.But while the blip is new, it’s dealing with familiar subject matter. Reactive architectures, extensions across languages, and other frameworks that use reactive programming techniques have all been on the Radar before.
ReactiveX is a post-hoc standard that was created to bring a lot of the various frameworks under one common API—and so we felt that it merited inclusion. It was put in Adopt directly because it was extracted from existing working frameworks that are really popular—and have been proven to work. In fact, the blip had already been in Adopt as "Reactive extensions across languages" and we resurrected it and renamed it inline with the new standard.
We remain cautious about moving anything directly into Adopt. In the case of ReactiveX, the fact that it’s not really new made it the right decision.
The Re-Emergence of Linux Security Modules
Eagle-eyed Radar watchers may have noticed that Linux Security Modules first moved into Adopt in the November 2016 release. But we’ve tagged it as changing because our thinking about it had changed.The blip originally talked about a number of aspects of Linux Security Modules. We wanted to emphasize the importance of MAC as a control, so felt it was right to redraft our write up.
We think that MAC is an important security feature that all developers should understand the purpose of and how to use. By limiting what an application can do, you can greatly limit what an attacker can do if they are somehow able to take control of it. In security terms we call that limiting the exposure. Sometimes we see people disable MAC when their operating system ships with it enabled rather than understanding how to use it correctly, which is actually disabling a very powerful feature.
Given that, we felt it was important that our Adopt recommendation was clearer. And we hope that will help Radar readers improve the security of their own Linux systems.
Thanks to Luciano Ramalho, Fausto de la Torre, Cade Cairns, Jonny LeRoy, Badri Janakiraman, Mike Mason, Martin Fowler and Rebecca Parsons, for their help and guidance in writing this piece.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
