When the Browser blog team asked me to write a ‘digital development trends’ post for the turn of 2022, I wasn’t sure at first. I tried to explain that most development macro trends that emerge over a long period don’t just drop conveniently in January – evolution rather than revolution, to use a cliched phrase – and any article would need to be deeper and more far-reaching.
‘Sounds great!’ was the reply (though, they did eventually snag a colleague to write that 2022 focused article, which is here). So here we are with some of my thoughts on the longer-term direction of travel for the development profession. In particular, I see a lot of influence in the way easily configurable SaaS products are going to impact project roles, and the need for developers to be open to change.
TL;DR: Coding isn’t just for developers anymore. We’re going to be coding a lot less; and, what code we are writing is going to be domain-specific.
Development roles are starting to blur
The traditional mentality running through the software world has often been the structure of who’s in charge of what: developers vs non-developers, back-enders vs front-enders. But I get a sense that we’re moving on from that mindset towards a more flexible, results-driven approach. Increasingly common are designers who have dev work in their portfolio and are looking to implement their own ideas, and fresh MBA grads coming into the organisation writing their own python scripts to get the data they want. Remember when we used to say ‘everyone should learn to code’? Well, they did.
Low-code and no-code solutions are also influencing macro digital development trends. The configuration options on web platforms like Wix and Squarespace are really strong. While today’s marketing managers may be learning to code, today’s developers might choose to configure existing services rather than code for the most practical, sustainable results. A colleague and I recently launched a client project to the public within 5 weeks of getting the proposal. The only code I wrote was some 15 lines of CSS to get the branding right, the rest was just wiring together a few services.
For smaller projects, there’s more expectation from clients that every developer is sufficiently full-stack to handle both the front- and back-end. There’s also some blurring between design and front-end development roles, especially with the results you can achieve through configuration. I can see some of these barriers eroding, and the definition of what a professional developer is or isn’t becoming increasingly vague.
I would encourage developers not to be precious about their roles or responsibilities. Here, the critical element will be ensuring that whatever roles are involved in your project, your stakeholders are at the centre. The project’s success is the most important outcome. Your ego should be a non-factor. Try to relax about who’s job role has the word ‘developer’ in it.
There’s a SaaS product for that
Conway’s Law states that when an organisation tries to design a system, it will eventually mirror the communication structure of that organisation. Even though this ‘law’ has been around for over fifty years, I think it’s very relevant to what I see increasingly happening in the CMS and web development space. Those large, monolithic and complex CMS or digital experience platforms are starting to not match the flexibility, agility and convenience that marketing and IT teams need.
If you feel like you’re fighting your CMS, then its days must be numbered. A more precise and useful product, usually available under some SaaS branding, will fill the gap better and reduce any friction; for the development community, that will mean less coding and more configuration. Conway’s Law may be an indictment of how we architect software to match the expectations of people who don’t architect software, but a different reading might be to take it instructively: ‘hey, fill the communication gap between accounting and project managers’ instead of ‘hey, re-architect our business’s communication structure to fit what WordPress allows’.
SaaS products have started to kill off waterfall approaches and that trend is only picking up speed. The quality of some of these products is high, meaning there’s no longer a reason to default to a waterfall project where you have a back-end developer, front-end developer, two-month timeline and a significant budget. Instead, you can have a strong MVP ready in two weeks, and even if it doesn’t do everything you need it to straight off the bat, you augment it subsequently. Perhaps the promise of AGILE methodology was in solution management instead of software engineering?
I think that, as developers, we need to be flexible and focus on what’s best for the website, content, experience and budget. That’s sometimes going to mean not working with the CMS or the approach we’ve been used to. It might sound obvious, but it’s about the right tool for the right job, and the right product for the right project. We’ll all be working with a much wider range of different SaaS products going forward.
Programming languages are transitioning
Ok, so far I’ve been mostly talking about digital development trends from the areas outside of coding. But hey, what about coding? Well, it doesn’t seem to be going away. Instead, it’s being integrated into other disciplines. But perhaps the ‘web developer’ might be going away. I know I’ve stopped using the term ‘web developer’ to describe myself except when at dinner parties where I need a short-hand for ‘I make code that people on the internet use.’ In 2014, web developer was the hot job. By 2024 the LinkedIn summary ‘web developer’ will simply mean ‘as of yet unspecified code-focused intern getting started in some industry‘. But how did we get here?
Indulge me in a bit of nostalgia: Remember web 2.0?
There’s a semi-cyclic nature to macro trends. Or maybe it’s a kind of ebb-and-flow? Some change (e.g. the introduction of smartphones) creates a paradigm shift in the market, all the competitors in the new space appear, then a sort of evolution takes place and the market stabilises into winners and losers, then the paradigm shifts again, and the whole thing repeats.
With that in mind, if we want to understand the first half of this decade then it is important to think about the first half of the last. We had just left a kind of Cambrian explosion of web tech at the end of the noughties. New frameworks like Ruby on Rails were taking hold, and there were rumours of server-side JavaScript; new targets like Android and iPhone OS, plus some new browser Google made; and new business needs like mobile-first (or mobile-only?!) apps. The scope of every new web app—and pretty much all web apps were new—exploded, and front-end frameworks like Bootstrap and Foundation were going to make it possible for everyone to serve all of them at once—’Write once, run anywhere‘ made manifest, just like Java promised in the 90s.
What happened? Where did the hot-new-JS-framework of the week go? Well, it’s hard to say for sure but I’ll give it a go.
We live in an island of stability
Thankfully, though painfully, that irrational exuberance that defined the previous decade stumbled on the mundane realities of software development and the marketplace inevitably contracted and stabilised in favour of the more productive products. In the JavaScript world VueJS and React were born alongside their not-yet-doomed competitors (Ember, Knockout, Batman, Meteor, AngularJS, Backbone, lodash), and as early as 2014 Ruby on Rails was being declared dead and predicting its imminent death remains a yearly tradition. Essentially, if your framework didn’t meet the needs of enough businesses it was going to be made redundant by one that did. That resulted in where we are today.
In today’s development world things are good™. By ‘good™’ I mean stable, performant, mature, and relatively hassle-free.
Despite its early reputation (earned or not) life is good™ in the JavaScript world. Typescript, like it or not, is good™. NPM, like it or not, is good™. VueJS and React are good™ — pick one and be happy. We don’t see so many JavaScript frameworks de jour any more because today’s JavaScript world is pick-your-preference instead of pick-your-poison.
The same can be said in PHP-land where life is also good™. Laravel and Symfony are both in very happy places. Sorry to the also-rans, but devs will be going where the jobs are and the Drupal and CodeIgnitor sections on job boards are thinning. (The weird outlier here will always be WordPress in its Schrodengerian state of both good™ and not good™.) PHP itself is no longer lacking supposedly-critical features and most of the recent updates are related to quality of life improvements.
Pick a language and you’ll find that we live in a time of great possibility thanks to the unforgiving evolutionary process that took place to define the winners and losers. If you want to build a website, web app, hybrid app, or whatever, all the tools you need are available. When we think about the tools, aside from stability and security, there’s not much more latitude for choice. We know what works and there are plenty of qualified and experienced developers to make them. In fact, you might not need to make them with high-quality, ready-made solutions available for many jobs as discussed previously.
Can we talk about tomorrow?
There’s something scripting languages aren’t offering us. Have you noticed it in conversations with other devs?
When was the last time you saw a non-legacy scripting language (i.e. not the old guard of PHP, Python, Perl, Ruby, JavaScript, etc) hit the market in a big way or take the interest of young developers? A few years ago the topic that dominated the keynotes at your favourite tech conference was paradigm: functional programming vs. object-oriented programming (OOP). We don’t seem to be interested in that conversation anymore. The outcome of all that discussion was simple, and should have been obvious from the beginning: follow whatever paradigm your language is best suited for, and make decisions based what is best for your product. So if the conversation isn’t about paradigm then what does the community want to talk about?
Where the digital development trends of the last decade were concentrated on frameworks, this decade’s are shaping up to be language focused. While the web devs were jumping from framework to framework, in parallel there was a less knee-jerk platform-native language revolution brewing. New purpose-built and mission-focused languages with serious communities and serious backers started to appear.
Overwhelmingly, the conversation has moved towards strongly-typed languages. I think we’re heading towards four or five major strongly-typed, multi-purpose languages coming of age and hitting maturity. TypeScript, Rust, Go, Kotlin, and Swift—some of which have major backers including Google, Mozilla, Apple, and my Patreon account—are likely to be the popular languages for the coming years, as well as some excellent associated web frameworks like Rust’s Actix-web, and Swift’s Vapor (an inevitable loser like Kitura, but a wonderful project nonetheless). It will be interesting to keep an eye on the annual Stack Developer overview to see how programming language popularity evolves over the next two to three years.
The languages I’ll be watching have a few things in common even though they came from different places: Go was built for the server; Swift was built for iOS development; Kotlin for Android; Rust for the browser; TypeScript for the web. All are strongly typed. All are purpose-built. All were stable and strong before taking their baby steps out of their intended space to herald in the new era of programming. We’re about to see each one take a stab at becoming this decade’s Vue or React.
To understand what the future will be like, we need to start to imagine what will be the victory conditions for any given language. For example, Rust has by far the best story if you believe that Web3 (1) is a real thing, and (2) will be around after the public finally loses interest in getting scammed by NFTs and whatever-coins. Type safety and runtime guarantees (like no race conditions) offer the kinds of promise that is critical to smart contract design. Rust’s most well-suited competitor in the space is TypeScript which offers JavaScript developers some amount of safety to stand up their prototypes quickly. Who will win: the disciplined Rust developer, or the nimble TypeScript kiddy? Either way, it will be a strong type system that enables them—if only for the branding. Who will lose? Just in time compilers, I suppose.
Each language I’ve mentioned so far has a story within their space that offers a compelling narrative for world domination similar to what I just described for Rust.
What could go wrong?
An important element of these growing languages and some of the associated frameworks is to make sure they have the right stewardship to generate trust in their long-term future and direction. Here, those big backers have done the right thing by going open-source. For example, when Apple open-sourced Swift they provided the community with not just the current version, they went all the way back to the initial commit. When these languages are purpose-built-yet-community-driven their long-term future is guaranteed—a walled-garden approach generates neither longevity nor trust and goodwill with developers.
Apple can exercise some control over Swift, but IBM and the public (among others) are contributing heavily and have quite a lot of influence. A story repeated in every language with any chance of success. Mozilla has relinquished control of Rust.
You sometimes see frameworks in seemingly perpetual beta where the cadence between versions is too long or the direction is questioned by the community. These frameworks are in danger of languishing and getting stuck in ‘hobby land’. Trust is fundamental for a framework’s success, and community trust can wane surprisingly quickly. Where Rust’s actix-web succeeds in this area (despite a little controversy around version 2), Rust’s Rocket framework has utterly flopped by being never-quite-ready even for the next minor version in its beta (currently at 0.5-rc1 for almost a year).
In summary
Software development and the role of back-end development is always evolving. The macro digital development trends of the next few years will mean the languages we use, the products we leverage for projects and the roles we play will change. The individuals and teams who succeed will be the ones who are suitably flexible in delivering the best possible value and outcomes for their clients.
Focus your energy on the future that is most productive and you’ll pick winners, and try to avoid the follies of the previous decade by getting involved with new technology too quickly. Early adopters pay the biggest fines, and entering late usually just means there’s plenty of documentation and stack overflow threads to get up to speed with.
The post Three macro digital development trends shaping the profession appeared first on Browser London.
Top comments (0)