What will software development look like in 2030?

What will software development look like in 2030?

Cast your mind back, if you will, to 2010.

Do you remember what the biggest leaps in consumer and business technology were back then?

It was the year that Instagram launched. The first iPad was introduced. Cloud computing went mainstream, with Microsoft Azure going up against AWS.

Major disruptors had yet to even enter the market. Uber? Not a thing until 2011. Same goes for Snapchat and Minecraft.

The most powerful games consoles in 2010 were the PS3 and XBox 360.

In the years since, technology has snowballed in its importance and its power. Tesla has made electric cars attainable, consumer drones have transformed content creation, and social media has evolved into a world-changing force.

But technology, and the software that enables it, has only just begun to explode.

What will the landscape look like in 2030?

Computing trends: so much power, still untapped 

Computing hardware is still mainly driven by Apple, Intel, AMD and Nvidia; and while they all depend on the same subcontractors, supply chains, and outsourced industrial processes – they are all independently racing towards new architectures.

Intel is famed for resting on its laurels, after establishing itself as the de facto chipmaker of the 1990s and 2000s. After that period, it was all AMD – but there was a push/pull relationship between the two silicon giants for the best part of the 2010s.

AMD eventually leapfrogged Intel for innovation and raw processing power in 2019, with the Zen architecture and its Threadripper series, effectively doubling the performance that Intel could offer, at any level.

And in 2020, Apple moved from Intel to processors designed in-house, with the M1 architecture; an entire system on a chip (SoC). This combines CPU, graphics and RAM into a single piece of hardware – one chip instead of many. While not the most powerful chips in the world, they remain, watt for watt, the most efficient desktop class processors in the world.

And it’s scalable. Shortly after M1 came M1 Pro, M1 Max and M1 Ultra; all use the same die, chopped, left whole or stuck together, for whatever level of power is required.

This started a chain-reaction of chipmakers developing their own SoCs to compete – and the race to become the most powerful, most efficient is now in full swing.

This means that consumers will have more power in their devices than ever before. Businesses will have faster machines, with less power consumption. Creators and the people behind the content we love will be able to make more compelling, beautiful, amazing experiences for us.

But all that power needs software to be able to utilise it effectively.

Otherwise, it’s a little like trying to drive an F1 car to the shops.

How will software change to use this new power?

Apple’s choice to transition from the established x86 architecture for desktops and into the ARM architecture (more traditionally seen on mobile devices) has caused some upset. Even two years after M1, and a full three since Apple announced the move, there are many flagship pieces of software that do not run natively on the architecture.

And this is just how it goes for new tech; devs and programmers have a lot of work to do in order to adapt. Making them from scratch is comparatively much easier – ARM has been around since 1990. But translating entire codebases to ARM is not as simple as it seems.

But it looks like this is where computing is going – and over the next five years, we expect developers and programmers to be focused on transitioning, because the software itself will have opportunities to become more powerful as a result of the improved power density that ARM offers.

This new power might bring new capabilities; like truly lifelike VR. Games could become more like simulations, and the much-touted metaverse could actually be realised in a way we can’t currently imagine.

Enhancing software to use the full potential of future hardware could make processes that currently take minutes or hours – like rendering large CAD or video files – instantaneous. 

Even for those of us who simply use tech to consume the content that we love, more power means more to be entertained by.

And the next revolutionary leap in tech won’t be hardware; it’ll be software.

Self-driving cars are physically possible with today’s hardware. We just don’t have the software to match. By 2030, we could have made that leap. We could have also given up our healthcare to technology over humans, our legal system, our educational institutions… 

And if that all sounds a little bit scary, well – it is. But we’re not here to discuss the pitfalls of a world run by AI this time around.

Except that is, if AI is making the software.

Will we even need devs by 2030?

Self-building software and AI-powered tools are going to explode.

Take DeepCoder, introduced in 2017. It’s a machine learning system that writes its own code, in much the same way humans do:

It takes existing snippets of code from other sources (in repos or from Stack Overflow and the like), and stitches them together. After it combines them, it tries to fill in the gaps – effectively determining which pieces of code are useful, and getting the desired outcome from chopping and changing.

Right now, it’s not very good. Humans are still better. But it’s learning – and ML, like humans, gets better as it does more work.

Unlike humans, ML never gets tired, and can continue improving at a geometric rate.

We will absolutely need developers and programmers in 2030. But by 2050? Machines could be doing all the work themselves.

Until then, we predict that the 2030s in software development will probably look like this:

  • A full adoption of Cloud Computing and centralised infrastructure
  • AI assisted software development, overseen by humans
  • Low code and no code building environments will enable more people to make software
  • New programming languages will emerge to utilise the latest tech
  • Artificial Intelligence will become far more advanced

Looking for a freelance DevOps expert?

ClearHub specialises in finding the best freelance DevOps experts in the world; vetted, skills-checked and ready to go. To get started, call +44 (0) 2381 157811 or send your message to info@clearhub.tech.

Software versioning: how to launch with FEWER complaints

sad face
sad face

Software versioning: how to launch with FEWER complaints

If you’ve worked in software development long enough, you’ll have lived through at least one “ropey” version release.

It could be version 2, or version 12 – but generally, the more complex a system gets over time, and the more features are added, the more likely you are to encounter an issue with a version launch.

And the larger a user base grows (on multiple devices, operating systems, browsers – you name it), the more opportunities there are for user error, bugs and incidents after a launch.

Sometimes, it’s inevitable; no matter how hard and diligently we work, we’re not perfect. But it’s frankly amazing how many issues can be avoided with a new version release – with simple, effective communication to your users.

Oh, and forget emailing your release notes, “HOT NEW FEATURES!” lists or press releases. Because half of the time, those emails go straight to spam. The rest either get ignored or misinterpreted.

Thankfully, there are better ways to communicate with your user base and ensure a smooth transition between versions – with fewer complaints and support tickets.

After release, users complain of reduced functionality – even if it’s all still there

A major release can be gruelling, even before changes are committed and rolled out. But once users are in the application – things can get messy.

Sometimes, functions and features are moved to make room for other, newer or higher-priority features. If you haven’t effectively communicated this to your users, expect a bunch of support tickets asking why they can’t do “that thing” anymore.

Remember – not everyone has the time to sift through their emails and read version notes. Many inboxes will filter out mailer bots, especially in high-pace, high-stakes organisations. So, while an automated email is an easy and simple solution for you, the people who actually matter aren’t getting the information they need, or it’s being presented in a woefully ineffective format.

Absolutely – you need to have version release notes. But does everyone need to read them? Think about a few ways to improve the release experience for users:

  • Add a “new features” pop-up to the login or launch screen. Keep it quick and simple, to prevent frustration
  • Get your PR and marketing teams to help develop key messages, or:
    • Write like a tabloid – give your users HEADLINE information of new features, then link to the full version release notes
    • Try a short “What’s new in version X” video explainer
  • Communicate over multiple channels, not just email. Have a solid message across all channels, and link to release notes

To stay ahead of the game, check forums for common issues with other releases (not necessarily your own) and try to preemptively mitigate any issues you encounter in them.

Uh oh. This actually IS an incident!

Incidents happen. And they’re serious. Speed of response is your greatest asset during a major incident, so make sure you’re ready.

Connect your CI/CD pipeline to Jira Service Management (or other ITSM platforms) to give your team a speed advantage when identifying issues that have just been released to the live environment. 

Good housekeeping is the key here; build categories using multiple attributes, so that high-priority items get noticed first. Set event thresholds on the number of linked incidents, and then define automated escalation paths.

Jira Service Management Service Centre and Confluence can work together to speed this up and communicate clearly during an incident. Use tags and keywords to raise content before a query is submitted.

When a high-level incident occurs, you will likely be following your major-incident process. Some of this will happen within your workflow, with automation and integration between your ITSM and documentation or collaborative workspaces.

Some of this will fall outside of ITSM; managing resources and relationships.

Senior leadership will be asking questions. Customers will be pushing back.

All the while, your dev team will be working hard, trying to resolve the incident. It can be tempting to bombard them with status requests when you’re getting the same. But be mindful of the impact this will have on their focus, their efficacy, and their wellbeing.

And be mindful of your own.

Major incidents are rare, but when they happen, you want to know you’re prepared to limit the fallout.

Is your Jira and Confluence set up to handle a major incident after a version release?

Hire an Atlassian expert to supercharge your workflows

ClearHub specialises in finding the best Atlassian contractors in the world; vetted, skills-checked and ready to prepare your DevOps and ITSM platforms to handle anything.

Want to know more? Get in touch with the ClearHub team today – call +44 (0) 2381 157811 or send your message to info@clearhub.tech.

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email

5 DevOps tips – all don’ts!


5 DevOps tips – all don’ts!

This blog is a safe space – so let’s just say it.

DevOps is hard work and boring.

There. We said it.

To most people in tech and software, DevOps is tedium and busywork that gets in the way of the “real” work – making software.

This is why it’s often left by the wayside, or done improperly. 

So, what if we told you that if you got it right, your job would be better, more fun, your business more profitable – all that kind of pie in the sky fantasy stuff?

The fact is – DevOps works. That’s why there are entire industries around it. But it requires the right mindset, the right skill set and the right people to really nail DevOps effectively.

If you can avoid the most common pitfalls, you’ll stay ahead of the competition. And in tech, you’re rarely at the top if you’re not one of the best.

Done right, DevOps delivers a fast, autonomous culture in a large organisation – where continuous product flow is the norm. But without guidance, teams will only ever pay lip service to DevOps, and never realise the potential of it. It’ll end up a box-ticking exercise, and eventually fall by the wayside again.

Don’t let that happen; in fact, don’t do a lot of things… 

Here’s a top 5 list of everything not to do when you adopt the DevOps culture.

1. Don’t skimp on skills

You can’t just say “hey, we’re DevOps focused now”, and leave it at that. You’ve got to invest in it for the desired outcomes.

You’ll need people with specific skills to get DevOps running effectively. You can train and upskill members of your team, or make new hires – or seek out contractors and DevOps consultants to help a small team transition, without committing to a new full-time employee.

Keep on top of training, and make sure everyone’s on board. Like we said – it can be boring to those doing the work day in, day out – so streamline it and make it simple where it counts.

DevOps can only succeed when everyone in the team is familiar and comfortable with the tools and processes. Give tailored access to tools and functions to individual members, to keep it simple – it’s more likely that they’ll integrate it into their day this way.

2. Don’t miss the metrics

With sophisticated analytics built into modern DevOps tools, getting data isn’t the problem; using it effectively is.

One of the biggest keys to success in DevOps is keeping track of progress. And to do this, you need the right metrics. By making the relevant measurements and then adjusting processes and tools, you’ll get the best results.

And if you don’t? You’re fumbling around in the dark. With no data to base your decisions on, you’ll have no insight into what’s working. Everyone wants to see different results and at different stages, so make sure the team and leadership all agree on goals before delving into DevOps.

3. Don’t choose tech over people

Automation, smart features, and advanced technology are no substitute for people. DevOps needs buy-in from the top down, champions in the company and collaboration throughout –  tech can’t provide that mindset. It can only facilitate it.

The success of DevOps depends on the bringing together of teams. Nothing happens without effective communication, collaboration, and cooperation. Culture makes companies successful, and the same goes for DevOps. That’s got to come from leadership and filter through everything you do.

And no – after work socials, a coffee machine and a ping pong table are not a company culture. But feeling safe to speak about problems and to communicate with key people across teams is a sign of a good one.

Put your people first. Run through new tech and processes with them first. Value them over the tech in play first. What’s good for your team is good for business – and for your DevOps strategies.

4. Don’t assume automation will fix everything

Automation is important – but working with legacy systems across multiple departments and siloed teams, it can be hard to know where to start. It’s easier in startups and small, agile teams, where things move quickly and teams are encouraged to fail fast. In older, larger, slower-moving firms, not so much. Automation takes time, and it may not become full or standardised over your tenure at the company.

A bad automated process is exactly the same as a bad manual process – it’s just bad.

Instead of automating, fix the manual process first: figure out where thighs fall off track, and how to improve what you already have in place. Then, seek to automate tasks within the process.

Test it on a live project that’s fairly low-stakes. You’ll need experience of it in practice, but don’t go all-in until you’ve established a framework for automation.

5. Don’t forget to rinse and repeat. Always repeat…

DevOps, completed it mate. Said nobody, ever.

DevOps is all about continuous, incremental improvement. It’s a marathon, not a sprint – or actually, it’s more like the development of an athlete. It takes dedication, drive, and a desire to be the best version of yourself. Talent alone won’t get the results; you need to constantly be working towards the goal, assessing performance accurately at each key phase, and making changes to improve weaknesses.

This goes for your product, your team, your process – everything. Good DevOps never stops. It’s not a destination, it’s a journey.

And if you need support, we’re along for the ride.

One more… Don’t forget to hire elite-level DevOps consultants

ClearHub specialises in finding the best DevOps consultants in the world; vetted, skills-checked and ready to get results.

Want to know more? Get in touch with the ClearHub team today – call +44 (0) 2381 157811 or send your message to info@clearhub.tech.


Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email