The development community has witnessed the emergence of new coding paradigms and approaches that have had a seismic change to how they work over the past thirty years. The mainstreaming of object-oriented programming in the early 1990s and the emergence of multi-core programming and web2 in the late 2000s are a few cases in point. More recently, Covid-19 has turned the development world on its head, forcing teams to adapt to a brave new distributed world. As we enter the second year of the pandemic, it is increasingly clear that these changes aren't going to be a temporal blip but rather may just stay with us for the foreseeable future.
So, what can we envisage for 2022?
Remote Working Drives Tooling
It's been almost two years since the world was tipped on its head. Tech roles, from software development to system administration, moved from the cubicle farm to the home office. Although some firms have fully embraced these seismic shifts, notably Twitter and Pinterest, others are still less keen.
Several Silicon Valley giants — most notably Google and Apple have set deadlines for a return to in-person working, although these have been pushed back repeatedly, following the emergence of the Delta and Omicron variants. Like it or not, remote working is here to stay for the near future. and this will influence how developer tools are made, configured, and used.
Some people are excited about how the shift towards remote work is impacting the choices in tooling that design and development teams make. We see a lot more globally distributed teams, and that is directly influencing which SaaS products (Software as a Service) are gaining traction in modern software companies. Products that take the friction out of async collaboration are experiencing a massive amount of growth, but we've reached the point that even companies which may have been late to react to the initial shift with COVID are now catching up.
What does this mean in practice?
Expect developer-facing SaaS products to compete for less on functionality but more on flexibility, interoperability, and ease of adoption. Scalability will be another key factor. The most successful tools will be those that can work equally well across whole companies as well as with small teams. Companies of all sizes are using way more SaaS products today than they did just a year ago, and we're seeing a distinct shift from top-down purchasing to autonomous teams championing the tools that they need to be effective. And because that autonomy directly translates to being happier and more productive at work. There is a bit of a renaissance in SaaS right now; products that solve problems well, are delightful to use and reduce friction in collaboration among distributed teams have an advantage over more traditional players that rely on top-down adoption. Those that can do all of that and also nail the land-and-expand motion – by fulfilling all of the "enterprise" requirements around single sign-on, security, compliance, and auditing – will be the clear winners.
Privacy, Engineering And Security Teams Working Closer Together
For the longest time, engineering operated as its own private silo, detached from the other tech-facing sides of the business: including security, operations, privacy, and governance. Over time, which has been changing you could say the real catalyst has been GDPR (The General Data Protection Regulation). With a maximum possible fine of €20m or 4 percent of total global revenue (in the EU), organizations have been incentivized to take data privacy and security seriously. Subsequent legislation, including the California Consumer Privacy Act (CCPA), as well as the upcoming California Privacy Rights Act (CPRA), only reinforced that. This will transform the organizational landscape, with engineering, security, and privacy teams working as a single coherent unit. These "shift left" principles are already being adopted in some workplaces.
As privacy laws continue to expand and as the regulatory bodies that govern them continue to hold organizations accountable, companies will not just be challenged with privacy by design, but by the concept of data protection as a service. Much like secure-by-design, Privacy by Design sees engineering and design teams consider privacy and compliance requirements at the start of the development process rather than as an afterthought. Data Protection as a Service (DPaaS), meanwhile, allows organizations to rapidly harden their privacy posture through the provisioning of discrete, cloud-based services.
This we believe offers a unique opportunity to bring teams such as privacy, security, and engineering closer together. Data privacy and data security roles will merge, as the responsibilities between them are further blurred, and the need for a cohesive unit will start to take shape.
The National Institute of Standards and Technology defines a DevSecOps platform as where security is ingrained during the design, building, deployment, and runtime phases. "Integrating Security into DevOps practices and workflows enable vulnerabilities to be detected and quickly remediated in every phase of the DevOps lifecycle". This doesn't just bring security and privacy benefits but is liable to accelerate the development process, as a 2020 study from GitLab found. A majority of organizations surveyed integrated DevSecOps into their workflows, and 83% reported faster code releases, with 60% able to achieve multiple daily releases.
Hybrid Events are Here to Stay
The COVID-19 pandemic added dozens of new terms into our collective lexicons, including social distancing, spike protein, and viral load. But let's not forget "Zoom fatigue," referring to the widespread disaffection with virtual meetings. It's fashionable to complain about how hard and alienating virtual events are and to celebrate on social media the first in-person events we are able to attend. In practice, however, virtual events are here to stay, at least as a hybrid model.
Conference organizers got a taste of the incredible reach they can achieve when offering an experience that doesn't require the money, time, and complexity traditionally demanded when attending an in-person event. Many conferences achieved record (paying) attendee numbers, reaching audiences traditionally off-limits. They won't give that up without a fight.
We expect a sharp increase in hybrid events, aimed both at developers and other interest groups, in 2022. Last year was the testbed for this model, but this will be the year when the industry irons out the wrinkles and brings hybrid events into the mainstream.
This increased reach has an unavoidable cost. Large sectors of the economy support in-person events, from airlines and hotels to catering firms. These sectors will be the biggest losers from this shift. Organizers will have to create the technological underpinnings to support these hybrid events, from conference apps supporting both in-person and online attendees to virtual expo booths and lead generation tools.
The software development sector exists in a perpetual state of change. New frameworks and technologies emerge. Coders wrestle with new paradigms. Culture continues to evolve. This has always been the case but has only felt truer over the past two years.
The emergence of the Omicron variant offers more uncertainty, with organizations pushing back their office re-opening dates and international travel feeling riskier than ever. For the time being, remote working and socially distanced webinars are here to stay.
Looking ahead to 2023 and beyond, it's possible that things might remain in flux. However, DEVs are comfortable with responding to change, and we are personally curious to see how working models continue to evolve.
Programming Languages:
With all that generalization and abstraction out of the way, let's look at tooling for the next couple of years knowing what we know now.
All development work starts with choosing the right tool from a toolset. If your toolkit only has one tool, an adjustable spanner for example you are likely to be found wanting when a situation arises where an adjustable wrench would be far more efficient and productive with or without a spanner. I digress.
The Backend:
Without reiterating all the current incumbents and the fact that WASM (web assembly) is now (almost)mainstream, we will look at the new kids around the block with potential.
#1Rust
A modern systems programming language focusing on safety, speed, and concurrency. It accomplishes these goals by being memory-safe and highly performant. Combine with WASM (Web Assembly - more later) and you can now create crazy backends for your web apps.
#2 Typescript
JavaScript superset, which provides insanely convenient type safety and auto-completion in many modern IDEs. The industry is gradually shifting towards development on a type-safe language and is transitioning away from the untyped JavaScript slowly - I hesitate to add.
#3 Python
Python is a clear and powerful object-oriented programming language, comparable to Perl, Ruby, Scheme, or Java. Any self-respected developer should have Python in their toolkit. The language is almost like JavaScript — learn once and use (nearly) everywhere. One can create small games, full-stack web apps, CLIs, etc. using Python only. It makes the language so convenient because one does not even have to leave the Python programming environment once tucked into a project.
Frontend Frameworks:
The game at the front-end has changed quite a bit during lockdown so it is a great idea to recap some of them that you will get familiar with in order to keep up with the latest trends.
#1 Svelte
Svelte is an innovative approach to building user interfaces. Whereas traditional frameworks like React and Vue do the bulk of their work in the browser, Svelte shifts that work into a compile step that happens when you build your app. Like the JavaScript frameworks mentioned above, which share a goal of making it easy to build slick interactive user interfaces. Rich Harris, the main developer, and maintainer of Svelte got hired by Vercel recently. This means more time will be spent on the development of the framework. This only bodes well for the framework.
Vercel is a tool in the Static Web Hosting category of a tech stack.
As React started progressing increasingly, developers became in need of another tool on top of it to manipulate the basic APIs more conveniently and effectively. Vercel came to the rescue. So, what is Vercel I hear you ask? It is a cloud platform for serverless deployment. It enables developers to host websites and web services that deploy instantly, scale automatically, and require no supervision, all with minimal configuration.
What is WebAssembly?
WebAssembly (abbreviated Wasm) is an intermediate layer between various programming languages and many different execution environments. You can take code written in over 30 different languages and compile it into a .wasm file, and then can execute that file in the browser, on a server, or even on a car, the so-called internet of things (IoT).
The name “WebAssembly” is a misnomer. While it was initially designed to make code run fast on the web, it now can run in a variety of environments outside of the browser. Moreover, WebAssembly is not assembly but rather a slightly higher-level bytecode. Porting applications to the web is the most basic thing it can do. The beauty of this paradigm is its interoperability. It is not limited to the browser. It has been used to make code work cross-platform and cross-device.
Programming Language Interoperability
Libraries and frameworks are usually written in a single language, which makes it difficult to make use of that code from other languages without a full rewrite. With WebAssembly, we can more easily execute code written in other languages. WebAssembly lets us more easily cross the boundaries between programming languages. This enables us to reuse code rather than reinvent the wheel.
Looking Ahead
Conway’s law state - an application’s architecture reflects the communication structure of the organization that produces it. Every new “reference architecture” throughout the history of computing has reduced the amount of coordination that is required between people. From mainframes to virtual machines to Docker containers, the number of people required to produce a deployable unit has progressively decreased. We’ve achieved this by decomposing systems into smaller and smaller components and by allowing the people building those components to work independently against well-defined interfaces. While microservices have decomposed monolithic applications into several small independent services, WebAssembly makes it easier to decompose microservices into even smaller components.