Media Query Source: Part 3

The responses I provided to a media outlet on April 11, 2017:

Media: How should companies choose new technologies to add to their tech stack?

My responses addressed the more detailed questions as follows:

Media: How can companies effectively choose the right tools and resist adding technologies just for the sake of adding them? 

Gfesser: The two big questions are (1) where are you right now? and (2) where are you headed?
 
These really speak to the current and future states of their tech stacks. I've often heard individuals refer to current state and future state in the singular, but software typically has many future states over the course of its lifespan, and companies need to understand the implications of this evolution.
 
Companies need to understand the purposes behind the decision making process for technology changes that are being made. Are these changes being proposed because of needed functionality, for example, or because of the technical direction things are going?
 
Functional needs are much simpler to defend because the implications are more visible, either to end users or to IT. For example, a JavaScript library may provide a UI capability that end users are looking to utilize as part of their daily routine, and a data streaming product might provide a centralized feed for downstream applications not visible to end users, but provides benefits to individuals managing the enterprise.
 
However, these benefits also have implications. What is the history of the JavaScript library? Is the JavaScript library being actively maintained? How strong is the community around the JavaScript library? Can these questions be answered more positively by competing libraries?
 
What is the history of the data streaming product? Is it considered a de facto standard in the industry? Is it a commerical product, or in the case of an open source product, has it been commercialized by multiple vendors? Can it be run both in the cloud and on premise?
 
Media: How involved do you think your entire engineering team should be in the decision-making process?
 
Gfesser: Closely tied to these lines of questioning is the deliberation as to whether development teams will want to work with these tools. Are they willing and able to pick up the needed skills to incorporate them into the tech stack and maintain them over the mid- to long-term? Not including teams in the decision making process can lead to dissatisfaction or even developers jumping ship if they think inappropriate decisions were made without their input. And tech stack decisions can have implications for bringing on new talent. What types of developers do they want to attract?
 

See all of my responses to media queries here.

Subscribe to Erik on Software

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe