App Development

Technology Radar Takeaways - Part 1: Techniques

Every six months or so, ThoughtWorks publishes the Technology Radar, their “thoughts on the technology and trends that are shaping the future.” Last month, they released the April 2016 edition. When a heavyweight like ThoughtWorks gives their view of the technology landscape, developers around the world take notice.

While ThoughtWorks usually has a more enterprise development focus, their opinions can still be useful. In this edition, they have included several mobile-centric technologies, some of which we’ve used, and some of which we haven’t. Now that we’ve had some time to digest the material in the latest Radar, let’s take a look at some of the items that affect us here at WillowTree.

*Note: The recommendations listed below (Adopt, Trial, Assess, Hold) are from the Technology Radar.


Products over projects (Adopt)

ThoughtWorks encourages us to think of software as a product that supports a business process, and that the product is not finished until the business process is no longer needed. This is in contrast to a one-off project that has a defined beginning and end. WillowTree has historically done work for clients as projects, but we have recently begun to view our relationship with clients as partnerships instead. This will naturally lead us to treat the apps we build as products.

BFF - Backend for frontends (Trial)

Working with APIs has been a challenge in the past. Many times, clients already have backend services built to support an existing solution, but those backends were not built with the requirements and constraints of mobile in mind. A BFF is a backend service designed for a specific type of front-end, and it can much better meet the needs of a mobile application. A BFF presents its own set of challenges, such as data caching and service orchestration, but one that is well executed could significantly decrease development time and maintenance costs.

Flux (Trial)

WillowTree’s web apps team has had a lot of positive experience with the Flux architecture. Tucker Legard, one of our senior web apps engineers, would have put it under Adopt:

Libraries like Redux aim to unify application state, and encourage functional programming. Simplifying application state into one point of control allows for easy debugging, and untangles a lot of the mental mapping you have to do with two way data binding. With React Native it could be even more beneficial to adopt a Flux-like architecture that can be shared across platforms.

Reactive architectures (Trial)

Reactive architectures have been all the rage lately, especially in UI programming. Tucker also suggests exploring other options:

Reactive programming is pretty easy on the Web with tools like Bacon.js, in conjunction with strong UI layers like React and Flux implementations like Redux. However, more advanced subscription patterns might be a stronger choice. In fact the blog for Elm, a language that quite a few members of the web apps team has their eye on, just announced that FRP programming and its complicated signals are dead.

VR beyond gaming (Assess)

With a VR app in the works, we already see huge potential in VR beyond just games. Devices like the HTC Vive solve many of the problems associated with VR, such as nausea and discomfort. But the true breakthroughs will happen when the weight, the number of wires, and the price come down. Zach Costa, one of our iOS engineers, is excited:

Imagine being able to tour a virtual version of your yet-to-be-built house to pick out tiles, or giving a 3rd grader a seat and a pen in Independence Hall, Philadelphia, PA on July 4, 1776. There are opportunities for VR in any industry where practicality limits how many people can experience something. VR is expected to have the same penetration as smartphones within the next decade, causing many companies to get in before they get left behind.

A single CI instance for all teams (Hold) Gitflow (Hold)

WillowTree teams make heavy use of Gitflow , the popular development workflow centered around Git. We also maintain a single CI instance for all teams. These techniques have worked well for us, so their placement under Hold won’t cause us to suddenly change up our process. But it could spark some interesting discussions as we strive for continuous improvement.

In the next post, we’ll look at the Tools and Platforms from the Radar.

What do you think? Do you disagree with us? Did we miss something? Let us know in the comments!

Thanks to Tucker Legard and Zach Costa for contributing to this post.

Xcode Cloud: Choosing the Right Continuous Integration and Delivery Tool for Your Team

Apple recently announced the release of Xcode Cloud at the latest iteration of their...

Read the article