The WHY Factor: Surviving the Tech Hype

1. What problem does it solve? 

It might seem a trivial question, but it’s fundamental to ask ourselves what problems a certain technology solves. Too often, companies gloss over this part and jump right onto the hype wagon without a good enough reason. When that happens, the outcome is usually predictable: failure. 

Take microservices as an example. So many companies announced their decision to migrate their software systems to microservices, yet many of those migrations ended poorly. Unless you have very different scaling requirements between services or the development teams are supposed to work independently from each other and on separate value chains, you probably don’t need microservices. If you migrate anyway, the common outcome is a distributed monolith where you need even more coordination than before among teams, and the overall deployment process becomes slower and more expensive. In many cases, working with modular monoliths gives you all the benefits you might expect from microservices. For example, you could use Spring Modulith to design modular Java applications. 

Therefore, it’s not enough to understand the problem a technology solves. It’s also essential to ask yourself whether the problem applies to you. For example, Kubernetes is a great technology for projects that need to orchestrate a high number of application workloads, scale dynamically, and support advanced deployments. If you don’t need those features, it’s a clue that Kubernetes might not be for you. I remember reading this case study about a company migrating its small blog to Kubernetes, then complaining about how much Kubernetes added to the complexity and the cost of the infrastructure. Of course it did! Kubernetes was not the right choice for that use case. Each tool has its purpose. It’s up to us to pick the right tool for the job. 

When it comes to Generative AI, understanding the problem is even more important. There is widespread misunderstanding about what Generative AI actually is. A good starting point is to recognize that AI is not synonymous with Generative AI. If your AI strategy focuses solely on large language models (LLMs) and other Generative AI technologies, it’s misnamed, and you are likely missing out on the broader capabilities of Artificial Intelligence. 

A common reason for companies to adopt Generative AI technologies is to reduce manual tasks by automating them, or to be more “productive” (whatever that means). However, it’s often the case that you don’t need Generative AI for that, as it’s not necessarily the best tool for the job.  

• Do you want to speed up the bootstrapping of new application projects?

Defining software templates using tools like Backstage rather than generating a new project from scratch with a GenAI assistant every time results in higher quality, stricter compliance, and faster iterations. 

• Do you want to deliver more features faster?

If your pipeline takes an hour to build your project, or if you need to go through a never-ending series of manual compliance tasks before releasing a new feature to your customers, outsourcing code generation to a Generative AI agent will not help. It will actually slow you down. Coding was never the bottleneck! Consider adopting modern build tools that follow SLSA and other supply chain security practices, and automating compliance using well-proven platform engineering patterns, supported by tools such as OWASP Dependency Track and Kyverno. 

• Do you want to process PDF documents, spreadsheets, slides, and images to extract structured data?

Large language models with visual capabilities can do that, but they’re also resource-intensive, can lead to data privacy or licensing issues, and are prone to hallucinations. If you use a Generative AI model to convert a document, be ready for it to make stuff up and include content that wasn't in the original document in the result. A safer approach would be to use a tool like Docling, an open-source, lightweight tool based on specialised machine learning models that can guarantee a faithful conversion of a document. If you use Java, you can check out the new Docling Java project (I’m one of the maintainers) to integrate your applications with Docling. 

After understanding the problem that a certain hyped technology solves and assessing whether you actually experience that same problem, you’re past the first barrier. Let’s explore the second one. 

2. How ready is it for production? 

A certain hyped technology might provide the perfect solution to your problem. But is it ready for production? Several tools out there have great potential, but if your goal is to deliver value to your customers and users, you need to ensure they are suitable for production. 

Imagine building a product and delivering it to your customers in production with a note stating that it might not work all the time. Do you think they would buy that? Would you buy a product like that? 

That’s what’s happening more and more often these days with products that integrate with large language models. If you have ever used a Generative AI-powered chat assistant like ChatGPT, you might have noticed a message in small characters at the end of the page stating that the assistant can make mistakes and that you should check its answers. Now, imagine applications used in sectors like finance, healthcare, or safety. Would you trust large language models to be run in production, powering potentially critical functionality in your applications? 

Once again, it’s important to understand how the given technology works. Only then can you assess whether it’s production-ready based on your use case. Testability and transparency are two key criteria for this purpose. Generative AI models are, by their very nature, not explainable and non-deterministic. Any scenario where we need to know how a decision was made, or ensure the same output given the same input, is probably not something we want to support with large language models.  

Does it mean we should never use large language models in production?

Not at all. They can actually be useful. To achieve a production-ready solution, though, we need to combine Generative AI models with a robust software architecture that supports enterprise use cases powered by them. Java is a great choice for this purpose. We’ve been using Java for decades to build secure and resilient enterprise applications. When it comes to Generative AI, we can rely on that strong foundation to build applications that can tame those models and make them part of more predictable workflows, suitable for production. For example, with Spring AI, you can infuse your Java applications with Generative AI capabilities while leveraging battle-tested libraries for observability, resilience, testing, and security. 

The choice of model also matters. Many commercial models lack transparency, especially when vendors do not disclose the datasets used for training. There have been cases where popular models were trained on copyrighted material without permission. For example, I discovered that my book “Cloud Native Spring in Action” was used illicitly by some major vendors to train their premium models. Using such models could expose your company to legal risks. It’s wise to consider models that are both open-weight and open-data, so you can properly assess their quality, legality, and suitability for your production systems. 

Unless you’re a large language model vendor, you don’t sell Generative AI services. You sell solutions to real-world problems that your customers face. What matters is the value you deliver, and you’re responsible for that. Instead of asking where you can introduce Generative AI into your system, reverse the question and start by understanding the problems your users face. Generative AI might enable solving problems that were not possible before, or using a better approach. But if we lose track of what users need, we risk embracing hype for no good reason. 

If you have established that the specific technology you’re evaluating is ready for production in your context, you’re past the second barrier. Let’s explore the third and final one. 

3. Yeah, but how about the developer experience? 

Alright. You found a great technology that solves your problems and is ready for production. Should you go ahead and adopt it? That depends: how good is the developer experience offered by this technology? 

I really like the definition of developer experience by F. Fagerhold and J. Munch (University of Helsinki), who describe it as “a means for capturing how developers think and feel about their activities within their working environments, with the assumption that an improvement of the developer experience has positive impacts on characteristics such as sustained team and project performance”. That means the better the developer experience, the higher the value produced. 

Many factors influence developers' activities within software engineering projects, including how developers perceive the development infrastructure. That includes interactions with tools, frameworks, platforms, and organizational processes. 

Let’s consider Kubernetes once again.

Kubernetes was never meant to be used directly by application developers, but rather by platform teams to build an end-user solution on top of it. However, in the early stages of Kubernetes adoption, it was common to ask developers to learn how to interact with Kubernetes APIs and to deal with additional infrastructure tools such as Istio. Very soon, it became evident that this wasn’t the right approach, which was increasing developers' cognitive load, preventing them from focusing on the application business logic, slowing down development teams, and leaking infrastructural concerns outside the platform team. 

That’s how platform engineering came to be: consolidating the idea that Kubernetes, Istio, and all the other tools used to build a platform are not meant to be exposed to developers, who are the end users of the platform and the reason the platform exists in the first place. Instead, a platform team is responsible for providing tailored APIs and experiences to development teams using tools like Crossplane, so they can consume platform capabilities without additional cognitive load. I was part of the team that authored the first white paper on cloud-native platforms for the Cloud Native Computing Foundation. If you’d like to learn more about such platforms, feel free to check out the paper. 

Since developers are the users and customers of such a platform, treating it as a product helps elicit requirements and prioritise work based on customers’ input. The idea is to build a platform that offers such a great developer experience that development teams ask to be onboarded and start using it. That’s what this point is all about. Developer experience is fundamental to getting the buy-in from development teams. The goal should be to create tools so compelling that developers themselves would ask to use them. 

Developers would have to spend every day working with that technology. If it doesn’t provide a good experience, makes them feel frustrated, or creates impediments and obstacles to their development workflows, they will not adopt it. It’s common to work around this problem by forcing development teams to use a certain technology. That might look like a successful move, especially if you only measure the adoption rate, but you risk developers leaving the projects, as many won’t put up with the daily friction these technologies create. 

If your desired technology passed the “developer experience test”, you’re ready to adopt it. And I wish you good luck! It’s always exciting to onboard a new technology in a production system.

The Developer's Perspective

Working as a software engineer is exciting. I love the continuous evolution of our field and enjoy experimenting with new technologies. However, when it comes to production systems, I rely on The WHY Factor to guide my decisions. And you? How do you distinguish between hyped and genuinely useful technologies? I’d love to hear your experience! Share your thoughts on Bluesky or LinkedIn.