Trending Topics
Trending
Reframing the RAMpocalypse
This article is part of our Opinions section, where we invite industry professionals to share their views on the most pressing technology questions of our time.
Global memory shortages (or the RAMpocalypse, as some have dubbed it) have most developers scratching their heads and scrambling to rethink their software development processes. It’s far from an ideal situation, but it also might be just what we need.
For too long, development processes have been morphing under growing time pressures as companies rush to innovate within shortening iteration cycles, with speed often prioritised over performance. As the latest DevOps Research and Assessment report found, the proliferation of AI technology might be increasing throughput speed, but at the cost of increased software instabilities. Previously, developers could lean on hardware for quick fixes, but with prices set to remain high throughout the next year, that’s no longer an option.
But just because hardware was the easiest option, it doesn’t mean it was the best one. This process of relying on hardware to bridge the gap is reliant not just on having access to that hardware in the first place, but also on your end users running your software on that same tech. And as rising costs continue to extend hardware lifecycles, that gap between development and real-world use will only expand.
In this new environment, we should turn the focus to the software itself to spark an optimisation comeback. Because without hardware to support the load, your software will need to be ready to step up. And that can only happen once we learn from the experience of embedded systems developers and adopt a learner approach.
No more get-out-of-jail-free hardware
Regardless of sectors, no developer is going to be spared this dilemma of what to do when hardware is no longer an option. But depending on what stage you’re at in the process, you’ll face different challenges.
For those with products already in the market, it’ll be a particularly complex challenge. Developers will need to assess their existing architecture critically in order to strip it down to those foundational decisions that can move the needle on technical debt. Compare your current software production with the original plan for the architecture and identify where you diverged – and most importantly, why.
Developers still in the development phase will have a slightly more straightforward path to this. For those fast approaching their launch date, a delay is likely the best option. By buying yourself extra time, you’ll be able to shift to cheaper hardware (e.g., move from DDR5 to DDR4) and optimise the software correctly to maintain the user experience.
But while one might be a simpler solution, both are far from ideal. And these fixes can only go so far when the goalposts keep changing. Today, we’re already seeing companies needing to renegotiate their RAM prices quarterly. So during development, your software stack might come out at 4GB of RAM, and at that time, 4GB modules are procurable at a profitable price point. But flash forward to the next quarter, when production begins and that 4GB has risen in price – suddenly your product is no longer financially viable.
Ending the cycle
While many of these circumstances are out of developers’ control, there is one element they can address: their reliance on hardware. These hardware procurement complications likely wouldn’t be having as much of an impact if developers weren’t so often relying on hardware to supplement inefficient software.
No developer sets out with the intention to create inefficient software that is reliant on hardware to prop it up. It’s emerged instead as an unexpected side effect of the ever-increasing rush to innovate. Teams are being pushed to create the ‘next big thing’, and of course, they dream big. But this often leads to a glaring disconnect between proof-of-concept designs and the real software needed to run on target hardware.
Concepts might be created with the coolest new features in mind, but in reality, they don’t consider what’s required to deliver the expected performance on real hardware – that falls to the developer left to build the product. And more often than not, these developers are also left to integrate multiple proofs and concepts into a singular software product. Facing rushed production timelines, bloated, unoptimized proof-of-concept code inevitably ends up getting shipped as developers stretch to deliver a product in line with these lofty concepts
And this is where the change needs to happen. We’re all familiar with the ‘shift left’ principle applied to testing, so how about we apply this to optimisation and performance? Because we’ll never see improvements in code optimisation unless we embed it into proof of concepts too.
Instead of measuring the development phases on core KPIs such as speed alone, we need to put memory usage and performance up there, too, from the very beginning. And embedded software has already shown us how. As any developer who has ever worked on an embedded system will tell you, hard caps on resources are a common occurrence.
Rather than letting your development teams go wild, set clear resource barriers – and make sure they are realistic. It’s not about restricting development teams; it’s about ensuring that the end product is optimised and profitable.
The Optimisation Renaissance
With a name like RAMpocalypse flying around, it can be easy to look at this situation negatively. And yes, it will be challenging. But it’s a change that’s much needed. In the not-too-distant past, big names had entire teams dedicated to optimisation, poring through software day in and day out to make it run leaner and better.
Today, while most developers will claim optimisation abilities, in practice, they’ll likely miss out on the granular details that add up to larger memory savings. To get through this hardware shortage, we’ll need true optimisation specialists – not generalists.
Take coding language, for example. Most developers will default to Python due to its convenience, but with shortages continuing, we’ll need to see optimisation developers with true language agnosticism. Rather than going with the easiest option, they’ll need to take a holistic approach, deploying different languages to suit different needs.
So for performance-critical layers, they might opt for C++ or Rust, using Python only where resources allow. These optimisation specialists will need this level of attention to detail to ask the right questions throughout the process. Not just what language to choose, but to explore selective caching and GPU offloading, for example.
Developing these optimisation skills might be an investment, but this expertise will be essential, not just for this shortage but beyond. Leading memory manufacturers are already favouring the production of High Bandwidth Memory (HBM) to meet demand from AI chips. So standard DRAM could remain limited, even as overall memory production recovers.
This RAMpocalypse might have highlighted the reliance on hardware, but the argument for optimisation won’t end here. The teams and developers who enshrine it as a core discipline now, rather than pushing it until later, will be the ones best positioned to deal with what comes next. Whatever that might be.
More from our Opinions section
About The Author
