By now, it has become an annual tradition at Gofore to conduct a Project Radar survey at some point of the year to gain better insight into our presently running software projects. The 2018 Gofore Project Radar builds on two previous Project Radar iterations, conducted in fall 2016 (in Finnish only) and spring 2017, containing a set of questions relating to currently employed tech stacks, development practices and projected (or hoped-for) technological changes. Most of the questions from last year’s Project Radar made their way into this year’s Project Radar to allow for year-on-year variation detection. We also added some new questions that were considered important enough to warrant their inclusion in the survey.
So with the 2018 Project Radar results in, what can we tell about our projects’ technological landscape? What can we say has changed in our technological preferences and project realities over the past year?
The Gofore Project Radar survey results for 2018 are in! [Click on the image to enlarge it].
End of JavaScript framework fatigue?
Over the past few years, the frontend development scene has shown intermittent signs of ”framework fatigue” as a steady stream of new frameworks, libraries and tools has flooded the scene, challenging developers to work hard to keep pace with the latest developments, current community preferences and best practices. A look at our Project Radar data tells us that at Gofore there has been no significant churn when it comes to primary frontend technologies employed by individual projects. Instead, the results indicate a distinct consolidation around React, Angular and Vue.js, the three major contenders in the JS framework race. All these three have gained ground on older frontend techs (AngularJS, jQuery etc.) and ratcheted up their project adoption percentage, React being the top dog at a near-50% adoption rate among projects represented in the survey. If given a chance to completely rewrite their project’s frontend, most respondents would, however, pick Vue.js for the job.
The fact that there was no major change from last year in preferred frontend frameworks is perfectly in line with developments (or lack thereof) on the frontend scene over the past year. While last year saw major releases of both React and Angular roll out (with Vue.js 3.0 still somewhere on the horizon), there were no new frameworks to come along that would have been able to upset the status quo and catch on big time in the community (regardless of distinct upticks of interest in at least Svelte.js and Preact). This stability comes in stark contrast to the unsettled years in the not-too-distant past when the balance of power between different JS frameworks was constantly shifting as new frameworks and libraries appeared on the scene.
Looking beyond the battle of JS frameworks, a significant trend with regard to frontend development is the ever-increasing share of single-page applications among our projects’ frontends. Around 64% of this year’s Project Radar respondents reported to be working with single-page applications, up from 57% in last year’s Project Radar results.
Node.js on the rise
Moving our focus to the backend, where Java has traditionally held a predominant position among our projects, a somewhat different trend emerges. While the Project Radar data clearly brought out a tendency toward consolidation around the three major frontend frameworks, the picture on the backend side, on the other hand, looks a little more fragmented. Last year’s Gofore Project Radar pegged Java usage at nearly 50% among all projects represented in the survey, trailed by Node.js and C# each with a 15% share of the cake. While Java still came out on top this year, it was reported as the primary backend language in only 32% of the projects, down a whopping 15 points from last year’s results.
This drop was fully matched by an upward surge by Node.js, which more than doubled its share of the overall pie, up 17 points from last year. While C# stood its ground at close to 15%, a crop of new languages, missing from previous years’ results, entered the fray in the from of Kotlin, Clojure and TypeScript. Regardless of there being only a handful of projects where they were reported as being primary backend languages, they contributed to the growing share of minority languages in our backend landscape, a group previously comprised of Scala, Python, Ruby and PHP.
Similarly to how respondents were asked to choose their hoped-for replacement tech for their frontends, we also asked our developers what was their preferred language for rewriting their backends if given the chance to do so. Last year most respondents would take the cautious approach and stick with their previously established backend languages. This year, however, there was considerable interest in rewriting backends in Kotlin, particularly among respondents who reported Java as their primary backend language (55% of all respondents were eager to switch to Kotlin from some other language).
Before drawing any conclusions from these statistics, it should be noted that upwards of 55% of respondents reported to be working with a microservices-type backend stack, suggesting that potentially multiple languages and server-side frameworks might be used within a single project. Still, the appeal of Kotlin, particularly among Java developers, is clearly apparent, as is the shift toward Node.js being the centerpiece of most of our backend stacks.
While the Project Radar does not shed any light on the reasons behind any technological decisions, the increasing popularity of Node.js can probably be put down to the above-mentioned prevalence of microservices-esque backend setups, where Node.js often slots in to serve as an API gateway fronting other services, which, in turn, might be written in other languages. Another contributing factor might be the emergence of universal JavaScript applications, where the initial render is handled by running JavaScript on the backend.
The popularity of Kotlin, on the other hand, has been picking up ever since Google enshrined it as a fully supported language for Android development. Considering its status as one of the fastest-growing programming languages in the world, its increasing presence in server environments is hardly surprising.
Going serverless
Now where do we run our project infrastructure in the year 2018? According to last year’s Project Radar results, more than two thirds (68%) of all respondents were still running their production code in a data center that was managed either by the client or a third party. This year, that number had come down to 59%. While this isn’t particularly surprising, what is mildly surprising, though, is the fact that IaaS-type infrastructure saw an even greater decline in utilization. Only 47% of all respondents reported to be running their production code in an IaaS (Infrastructure as a Service) environment, as opposed to 60% last year.
As the utilization of both traditional data center environments and IaaS services fell off, PaaS (Platform as a Service) and, especially, serverless (or FaaS, Function as a Service) platforms were reported to take up a fair portion of the overall share of production environments. While still in the minority, PaaS services were reported to be used by 12% of all respondents, tripling their share of 4% from last year, and serverless platforms by 16.5% of all respondents (no reported usage last year as there was no dedicated response option for it).
As our projects’ production code is more and more removed from the actual hardware running it, containerization has also become more commonplace, as evidenced by the fact that Docker is now being used by 76% of all respondents (up from 43% last year). Despite Docker’s increasing adoption rate, there wasn’t much reported use for the most popular heavy-duty container orchestration platforms: Kubernetes, Docker Swarm, Amazon Elastic Container Service and OpenShift Container Platform were only reported to be used by 14% of all respondents.
Since running our code in cloud environments enables shorter deployment intervals, one could think we’d be spending more time flipping that CI switch that kicks off production deployment. And to some extent, we do: we have fewer projects where production deployments occur only once a month or less often (10% as opposed to 20% last year), but, somewhat surprisingly, fewer projects where production deployments are done on a daily basis (10.5% vs 12% last year).
Miscellaneous findings
- Key-value databases doubled their reported project adoption (32% vs 16.5% last year)
- Jenkins was the most prevalent CI platform among represented projects, with a 57% adoption rate (its closest competitor, Visual Studio Team Services/Azure DevOps well behind at 17%)
- Close to nine percent of all respondents reported to be using a headless CMS (Content Management System)
- Ansible was being used by 71% of respondents who reported using some configuration management (CM) tool, clear ahead of any other CM tools (Chef was being used by a little shy of eight percent of CM tool users, while Puppet had no reported users)
- Development team sizes were smaller than last year (57% of dev teams had five or more team members last year, whereas this year such team sizes were reported by 52% of respondents)
- The reported number of multi-vendor teams was smaller than last year (41% vs 47% last year)
- Most respondents reported to be working on a project that had been running 1-3 years at the time of responding
- Most project codebases clock in at 10k – 100k in terms of LOC (lines of code)
- Scrum was the most favored project methodology, being employed by nearly 51% of all represented projects. Kanban, on the other hand, saw the most growth of any methodology (22% vs 12% last year)
Some closing thoughts
Once again, the annual Project Radar has told us a great deal about our preferred programming languages, frameworks, tooling and various other aspects of software development at Gofore. While the survey is by no means perfect – and I can easily come up with heaps of improvement ideas for the next iteration – the breakdown of its results enables us to more easily pick up technological trends in our ever-increasing multitude of projects. This year’s key takeaways are mostly reflections of industry trends at large, but there are some curiosities that would be hard, if not impossible, to spot if not for the Project Radar. The usefulness of these findings is debatable, as some of them fall under trivia, but still they come as close to a ”look in the mirror”, technology-wise, as one can get at a rapidly growing company of this size.
