AI Insights

The start of a new year is the perfect moment to clear out what’s no longer needed – and technology is no exception. Some tools and platforms lose their relevance over time, and it’s time to let them go. We asked Head of Java, Dmitry Kvartalny, which technologies he’s ready to part ways with, and which ones are still riding high.

When you think about the phrase “technologies we have to say goodbye to”, what comes to mind first?

To me, the phrase immediately recalls the Opportunity Tax. In software leadership, saying goodbye to technology isn’t just about deprecating old code; it’s a conscious decision to stop subsidising the past at the expense of the future.

In the engineering ecosystem, we often fall into the trap of ‘if it isn’t broken, don’t fix it.‘ But ‘not broken’ is a low bar. I think of the technologies that have become bottlenecks to velocity – tools that require specialised ‘tribal knowledge’ to maintain, or frameworks that force us into 10-minute build cycles and monolithic deployments. When I hear ‘saying goodbye,’ I see a necessary liberation. We are clearing away the technical debt that acts as a silent tax on our innovation, allowing the team to shift their energy from ‘keeping the lights on’ to building features that move the needle for our customers.

Which technology or tool do you personally hope to never work with again?

I hope to never return to the era of ‘Manual Boilerplate Engineering.’ Until very recently, even the most senior Java developers spent a staggering amount of their day writing ‘dumb’ code: DTOs, repetitive mapping layers, boilerplate unit tests, and the ‘glue’ that connects services. We treated this as a standard part of the job, but in reality, it was a massive drain on mental energy and project budgets.

With the rise of AI-augmented development and smarter, meta-programming-heavy frameworks, that ‘busy work’ is finally becoming a relic of the past. I want all of us to focus more on high-level architectural puzzles, security, and business logic – the things that actually require human intuition.

Is there a technology or tool you had to give up, even though you would have preferred to keep using it? Why?

Honestly, I’ve always viewed technology through a pragmatic lens – It’s an evolution, and I don’t tend to form emotional attachments to tools that have reached their expiration date. However, I’m currently observing a ‘forced goodbye’ to the traditional IDE as we know it. For decades, the IDE was the ‘command centre‘ of a developer’s life – a massive, resource-heavy suite that managed everything from refactoring to deployment. I’ve always enjoyed the deep mastery of a complex IDE, but we are reaching a point where these tools are becoming redundant. With the rise of LLMs and AI agents that can reason about code across an entire repository from a simple terminal or a lightweight text editor, the ‘heavy’ IDE is starting to feel like an unnecessary middleman. We are giving up the ‘comfort’ of the traditional, feature-rich interface in favour of a more fluid, AI-driven workflow. It’s a bittersweet transition; you lose the familiarity of the tool you mastered over 20 years, but you gain a level of speed and decoupling that makes the traditional IDE look like a fossil.

Is there any ‘old’ technology that you think still deserves respect and shouldn’t disappear completely?

Absolutely. I believe the Monolithic architecture deserves significant respect and a seat at the table in modern discussions. Today, we often treat ‘monolith’ as a synonym for ‘bad practice,’ but that’s a misunderstanding of engineering.

A well-structured monolith is often the most pragmatic starting point for a project. It simplifies delivery, reduces operational overhead, and eliminates the ‘network tax’ of microservices. In the early stages of a product, you need velocity and the ability to refactor across boundaries easily – things a monolith excels at.

Alongside this, I’d include Relational Databases, SQL, and classic OO principles. These are ‘load-bearing walls’ for a reason; they embody decades of lessons on data integrity and system boundaries. The real risk isn’t using ‘old’ technology; it’s using it without understanding why it was created. Old technologies shouldn’t be dogmatic defaults, but they should be respected reference points that help us build smarter, more grounded systems.

How dangerous is it for developers to rely on ‘what worked 10 years ago’?

The danger isn’t in the tools; it’s in the stagnant mental models. Relying on ‘what worked 10 years ago’ means you are likely solving problems that no longer exist while ignoring the constraints of the modern era.

Ten years ago, we architected systems around the limitations of physical hardware or early-stage cloud providers. We over-indexed on manual ‘plumbing’ because we had to. Today, the landscape is fundamentally different. If a developer applies a 2016 mindset to a 2026 project, they will likely over-engineer solutions that the platform now handles natively.

For example, in the Java world, the way we handled high-concurrency 10 years ago (complex thread pooling and reactive programming) has been revolutionised by Project Loom and Virtual Threads. Sticking to the ‘old way’ doesn’t just make you slower; it makes your system more complex and harder to maintain than it needs to be. The ultimate risk is intellectual debt: building a solution that is technically ‘correct’ by yesterday’s standards but a liability in today’s ecosystem.

What risks do companies and their customers face when they refuse to modernise technologies and tools (financial, cultural, or technical)?

Refusing to modernise creates a compound interest of risk across all three fronts:

1. Financial: It’s an ‘Innovation Tax.’ Studies in 2026 show that companies spend up to 80% of their IT budget on maintenance, paying a premium for specialised legacy skills and bloated infrastructure. You’re essentially paying more to move slower than your competitors.
2. Technical: Security and integration are the biggest losers here. Legacy systems often can’t support modern ‘Zero Trust’ security models or integrate with AI-native workflows. You become an island, unable to participate in the modern ecosystem of automated agents and real-time data.
3. Cultural: You face a silent ‘Brain Drain.’ High performers want to build, not just patch. When the complexity of managing technical debt outweighs the joy of creation, your most valuable assets, your people, start looking for the exit. For customers, this manifests as a ‘frozen product’. They see fewer updates, more bugs, and a user experience that feels like a relic of a different decade.

What technologies do you think we’ll be saying goodbye to in the next 5 years?

In the next five years, I believe we will finally say goodbye to ‘Static Infrastructure Management.’ For years, even in the cloud era, we’ve still been ‘babysitting’ instances – worrying about heap sizes, container orchestration, and manual scaling limits. We are moving toward a ‘No-Ops’ reality for the application layer. Between the maturation of GraalVM Native Images (which allow Java to start instantly and consume minimal memory) and AI-driven autoscaling, the concept of ‘managing a server’ will become a relic.
I also believe we will see the sunset of complex Reactive Programming models (like WebFlux or RxJava) for standard enterprise apps.

Now that Project Loom and Virtual Threads have made high-concurrency code simple and readable again, the ‘reactive’ style – which is notoriously hard to debug and profile – is losing its primary reason for existing. We are returning to a ‘thread-per-request’ model that is as simple as it was 20 years ago, but with the performance of a modern asynchronous engine. We’re saying goodbye to complexity to improve performance.