Recently, I participated in a focus group where developers were asked to discuss how they make technology adoption decisions. Even "the big guys" seem unsure of how to get developers to notice and adopt their products. So, in this post, I'm going to try to reduce our learning and adoption process down to some concrete steps. The truth is, we don't just pick up tools, components, libraries, or languages just to complete a particular task or project. In truth, any technology we adopt has to help us do one or more of three important jobs. The more of these jobs your product can do, the more likely developers will pick it up and stick with it.
Job #1. Staying ahead of the curve.
As developers, we're constantly navigating through a meteor shower of new frameworks, platforms, and libraries being hurtled at us at blinding speed. Somehow, we are driven and expected to possess a "technology radar," a sense of what the next big platform or paradigm is. When the business need for a new technology arises, we must be ready to leverage that new technology or fall behind other developers who are.
So, does a developer sense which way the technological winds are blowing? We are ordinary mortals (however reluctant we may be to admit it), and the mechanisms by which we perceive “the next big thing” are often products of habit and evolution rather than conscious choice. Here are a few:
Influencers. Everyone is promoting something, but we are most likely to listen to those who have already earned our trust or gained our rapport. These can be highly esteemed thought leaders (e.g. Martin Fowler) or senior colleagues and friends.
Social Proof. Humans are wired to emulate the behavior of their surrounding society. Sometimes this means facing the wrong way in an elevator when everyone else is facing the wrong way. And sometimes it means getting excited about technologies that those around us are excited. For those of us who, at one time, were invested in bloated J2EE and WS-* Web Service, this can be a source of some comfort.
The Availability Heuristic. We tend to accept the familiar thing as the truth. So when we seek to read up on some hot new web framework or programming language, we may well choose to catch up on the first one that comes to mind.
These processes can lead us to determine which platform, language or tool to get to know in order to “stay up to date.” It’s important to note here that the desired outcome of “staying up to date” is not mastery of the tool being studied. Rather, the desired outcome is an assessment of the features and developer experience of the software, as well as its fitness for any potential development uses.
Thus, for staying up to date, a developer need not even employ the technology itself. Rather, he or she may most immediately rely on the tool’s website, documentation, tutorials, and examples. Therefore, it is crucial for technology products to reveal their value up front. An application example showing a real-world scenario reveals the value of a programming language much more quickly than a lengthy tutorial that goes through a high-level overview, installation instructions, and a contrived “hello world”-like the program.
Once we’ve assessed the value proposition of the tool, we may become curious enough to investigate it more extensively or file it away what we’ve learned until it’s time for job #2.
Job #2: Getting something into production.
Most developers won’t get to leverage every hot new technology in their work life. But occasionally, many of us do get to choose a platform or a technology to use in our day jobs, delivering value to our employers and customers. If the job at hand cannot be done with a technology already known to us, we are forced to repeat Job #1 at an accelerated pace. The unconscious permeation by influencers, social proof, and availability becomes replaced by intentional research in this scenario. The ability of the candidate product to reveal its value up front becomes even more crucial.
However, chances are we‘ve already come across a technology that’s a candidate for the job at hand.
Most likely, it’s a technology we’ve already used in a production-bound project. Such a technology has a gargantuan home court advantage. The greater the pressure, the more likely we are to err on the side of the familiar.
When the job calls for a technology in a category we haven’t used yet for a production-bound job, that home court advantage goes to the technology we’ve become familiar with in the process of “staying up to date.” So, if one candidate technology has become familiar to us through influencers, social proof, and accessibility while another has not, our preference toward the familiar technology will be disproportionate to its objective merits.
Once we’ve selected a technology for a production-bound job, our experience and outcomes with that technology serve to determine whether the technology is “rehired” for the next production-bound job. The totality of these experiences can play a part in determining whether the technology is adopted for the ultimate and most glorious job of all, job #3.
Job #3. Keeping us happily employed.
Why do so many engineers, teams, and enterprises still learn and use Java, all while whining continuously over its verbosity, type erasure, mammoth footprint, and more issues? The Tiobe index, which tracks programming language adoption, shows Java well ahead of the herd through most of the last 15 years. I’ve already discussed the attraction of familiarity, but 15 years is enough time for any technology to become significantly ubiquitous and familiar. And the next two runners up, C and C++, are even older.
So why are there so many Java developers? Because it “runs everywhere?” Possibly, but most of the time java applications run on the enterprise backend, which can usually be made to conform to tight specifications. What most of us will not readily acknowledge - but know to be true - is that our most important job as engineers is not to deliver value to an employer or a customer. An engineer’s most important job is to get and to keep a job. Java has a proven track record of keeping engineers, including this engineer, happily employed for many years. This is why, for all the latest-and-greatest languages that have come since, Computer Science graduates today come into the workforce knowing Java.
How did Java get to this lofty position? In the enterprise, IBM, BEA, and others marketed proprietary J2EE solutions aggressively to the enterprise. Broad enterprise adoption created a large developer ecosystem, which gave rise to tooling and libraries that have kept Java developers sufficiently effective and therefore content to maintain the ecosystem.
Here's an even more striking example of the power of enterprise adoption: Salesforce. Some may struggle with the notion of resting one’s career on a closed, proprietary cloud platform. However, according to an IDC analysis, by years end of 2015 through 2020, the Salesforce ecosystem will generate 1.9 million jobs among Salesforce customers. A 2014 breakdown by Business Insider found that “Salesforce Architect” was the most valuable skill to have on a tech resume, in terms of impact on salary. There are entire recruiting firms dedicated specifically to placing candidates with Salesforce skills. Despite the risk of subjecting one’s career to vendor lock-in, the demand for Salesforce in the enterprise has led to its adoption by hundreds of thousands of developers.
Enterprise adoption is not a necessary condition for developer adoption, but it is a sufficient condition. So when a technology is effectively marketed to and reliably supported for the enterprise, developer adoption follows.
If you build it, will they come?
No technology, however great, is adopted in a vacuum. To be adopted widely, a technology needs to register on developers’ technology radars, be adopted by business, and work effectively and reliably in production. Excelling at all three of these jobs may be a tall order, but when this miraculous confluence happens, the entire tech world takes notice.
For a framework for building enterprise Java microservices visit WildFly Swarm.
Last updated: April 19, 2017