Logo of Osakidetza, the Basque Health Service, featuring a modern design with clouds and abstract elements.

256_cta-background.webp

384_cta-background.webp

640_cta-background.webp

750_cta-background.webp

828_cta-background.webp

thumbnail_cta-background.webp

osakidetza-logo

Daar hebben wij de oplossing voor

Wilt u efficiënter werken? 

Abstract digital background featuring interconnected lines and glowing points in shades of blue and green.

1080_background.webp

1200_background.webp

256_background.webp

384_background.webp

640_background.webp

750_background.webp

828_background.webp

thumbnail_background.webp

atmosphere-water-sky-azure-electricity-astronomical-object-slope-electric-blue

Logo of Zen Software in white on a transparent background.

1080_zen-logo-white.webp

1200_zen-logo-white.webp

256_zen-logo-white.webp

384_zen-logo-white.webp

640_zen-logo-white.webp

750_zen-logo-white.webp

828_zen-logo-white.webp

thumbnail_zen-logo-white.webp

zen-logo-white.webp

ZEN Software

1080_zen-logo-black.webp

1200_zen-logo-black.webp

256_zen-logo-black.webp

384_zen-logo-black.webp

640_zen-logo-black.webp

750_zen-logo-black.webp

828_zen-logo-black.webp

thumbnail_zen-logo-black.webp

západoslovenská energetika-logo

Project Reinforcement

New Software Project / Modernisation

Tech Consultancy

Cloud Consultancy

What We Do

Cases

About us

News

Contact

Success! You`ve been added to our email list.

Subscribe to our email list and we will keep you updated on DevOps and ZEN Software News and Trends

Subscribe to ZEN Software's  newsletter

The $100 billion product demo failure: Google’s BARD

TV-host promotes tech news, displayed on TV-show via fancy

television-presenter-product-world-news-television-program-font-suit-display-device

Since the launch of chatGPT, it’s been DEFCON 1 at Google HQ. ChatGPT could easily lead to a golden-egg-laying-goose killer for Google: Google’s Search Ads business. Basically, Google has been printing money since their invention of Google Search Ads, and their top-dog position has been unchallenged for ever so long; this may all change now.


The $100 billion product demo failure: Google’s BARD 

With the launch of ChatGPT, Google may now be challenged in their core revenue stream, the search ads. This warrants a formal answer in the form of a good rival to chatGPT: say hello to BARD. 

What better way to say hello to BARD than using an interactive demo? Things did not go too well with the demo. After the demo, **Alphabet's share price fell around 8 pct to $99**, wiping around $100 billion off its market cap. 

The team at Google probably forgot to appease the Demo Gods. When you are planning a demo, you must appease the Demo Gods, or their wrath will surely strike you down, making you appear to be a total fool in front of your professor, your fellow students, your co-workers, or in the case of Google: the whole world. 

The following time-honoured rituals are unsurpassed in their power to appease the Demo Gods and perhaps even to make them smile upon you:

-  *Never* exercise *any* capability in your demo that you have not *thoroughly* tested beforehand. If you have not tested it, it does not work, no matter how careful and clever you thought you were and no matter how simple the code seemed at the time.
- Rehearse your demo as if you were rehearsing a play.

…. with the rest of the list on how to appease the demo gods [here](http://www2.rdrop.com/~paulmck/DemoGods/).

A GIF shared by Google shows Bard answering the question: “What new discoveries from the James Webb Space Telescope can I tell my 9-year-old about?” Bard offers three bullet points in return, including one that states that the telescope “took the very first pictures of a planet outside of our own solar system.”

However, a number of astronomers on Twitter pointed out that this is incorrect and that the first image of an exoplanet was taken in 2004 — [as stated here on NASA’s website](https://exoplanets.nasa.gov/resources/300/2m1207b-first-image-of-an-exoplanet).

Rather than querying a database of proven facts to answer questions, they are trained on huge text corpora and analyze patterns to determine which word follows the next in any given sentence. In other words, they are probabilistic, not deterministic — a trait that has led one prominent AI professor to label them “bullshit generators.” or, in an academic explaining term ‘**stochastic parrot’**, or; 'well-guessing parrot' in normal English.

Google has 175,000+ capable and well-compensated employees. The company had been leading the world’s search business for more than 20 years and is now showing signs of suffering from a number of corporate ailments. These ailments seem very familiar to ‘older companies’ where employees tend to get very little done quarter over quarter, year over year. 

Like mice, they are trapped in a maze of approvals, launch processes, legal reviews, performance reviews, exec reviews, documents, meetings, bug reports, triage, OKRs, H1 plans followed by H2 plans, all-hands summits, and inevitable reorgs. 

The mice are regularly fed their “cheese” (promotions, bonuses, fancy food, fancier perks), and despite many wanting to experience personal satisfaction and impact from their work, the system trains them to quell these inappropriate desires and learn what it actually means to be “Googley” — just don’t rock the boat. 

As Deepak Malhotra put it in his excellent [business fable](https://www.amazon.com/Moved-Your-Cheese-Someone-Business/dp/1609940652), at some point the problem is no longer that the mouse is in a maze. The problem is that “the maze is in the mouse”.

Google started suffering from four core cultural problems. They are all the natural consequences of having a money-printing machine called “Ads” that has kept growing relentlessly every year, hiding all other sins.

[(1) no mission, (2) no urgency, (3) delusions of exceptionalism, (4) mismanagement.](https://medium.com/@pravse/the-maze-is-in-the-mouse-980c57cfd61a)

While things are not looking bleak yet for Google, earnings and revenue are fine: Google’s 2022-Q4 consolidated revenues are **up 1% year over year** (to $76 billion), and for the full year of 2022: $283 billion, **up 10%**. 

In the mid and long term, Google’s unchallenged status in the search business seems to come to an end. This means ‘us mere mortal consumers’ may finally have something to choose again! which would be a net positive for all!

Google recertification

Tech office space: computer, peripherals + plant alongside a personal computer

computer-personal-computer-peripheral-plant-output-device-table-computer-desk-computer-keyboard

For Google Recertification assignment nr 1 is to scan your workplace to see if there are any hidden devices that could influence the exam.

All was fine and the exam was a **PASS**! I’ll be a certified Solution Architect for another 2 years.

ZEN Software is now Google Cloud Partner!

Modern electric-blue logo with rectangle, font & trademark graphics, showcasing

rectangle-font-brand-graphics-logo-electric-blue-symbol-trademark

As Hyperscale clouds are concerned: Google is a top-tier cloud provider. With its launch in 2011, thus the newest player in the market, GCP has quickly secured a stable market position with a unique offering in Big Data and AI services.

As Hyperscale clouds are concerned: Google is a top-tier cloud provider. With its launch in 2011, thus the newest player in the market, GCP has quickly secured a stable market position with a unique offering in Big Data and AI services.

With ZEN Software’s certification as an official [Google Cloud Partner](/what-we-do/products-and-services/google-workspace-and-google-cloud), customers can confidently lean on ZEN Software’s cloud specialists to secure an agile and flexible cloud infrastructure that matches their businesses. Together we will leverage the innovative Big Data, AI and world-class infrastructure of Google

The recognition builds on ZEN Software's status as the preferred cloud-neutral provider of multi and hybrid cloud solutions, helping customers leverage the total value of the Google Cloud Platform.

Code is getting cheap. Engineering isn't.

Two panels: implementation priced at 150 euro an hour, struck through with a downward arrow, beside engineering judgement marked scarce with an upward arrow.

code-is-getting-cheap-en.webp

A developer with twenty years' experience stopped coding with AI — not because it failed, but because it worked too well. His diagnosis is sharper than most of what the vendors are selling. We just reach a different conclusion: not less AI, but better engineering around it.

Brett Chalupa has been programming for twenty years. He recently published a video on his channel Brett Codes called [I'm done coding with AI](https://www.youtube.com/watch?v=2ZU3j4GQ4K8) — not the video the title suggests.

The lazy version of this genre says the tools don't work. Brett says the opposite. He was skeptical of Copilot, came round to agentic coding in 2025, and watched himself ship more software than he could have written by hand — connecting Linear to Claude Code and getting non-trivial projects built without editing a line. That worked, and anyone arguing with the rest should sit with that first.

His problem started about a year in, and it wasn't productivity. The agents produced more code than he could meaningfully review. He felt detached from codebases nominally his. He was learning less, because he had stopped struggling with implementation — and the struggle was where the learning lived. He cared less about code he hadn't written. More output wasn't becoming more revenue or better products, and when generation is nearly free, little stops a team shipping features nobody asked for. His role had flattened into reviewing someone else's work: "basically just a hamster on a wheel, checking boxes," as he puts it. So he stopped, and went back to writing code by hand.

The important parts of that are almost certainly correct. His argument compresses to a chain of inequalities worth pinning above every engineering manager's desk — more code is not better software, better software is not more customer value, and none of it automatically produces better engineers. [Review capacity](/articles/ai-assisted-code-reviews-what-the-latest-research-reveals-about-gpt-in-pull-request-workflows) as the true bottleneck. Ownership decaying when nobody wrote the thing. Cheap generation quietly financing feature bloat. We have written before about how [generated code is not automatically good](/articles/the-reality-check-llm-generated-code-vs-human-engineers), how [constant AI assistance wears people down](/articles/ai-fatigue-in-development-why-constant-ai-assistance-can-wear-you-down), and how AI erodes [the path from junior to senior](/articles/if-ai-replaces-junior-roles-where-do-senior-developers-come-from).

I just don't arrive at his conclusion. Brett's answer is to stop using AI. Mine is that software engineering itself has to change.

The business model nobody quite wants to say out loud

So here it is: the days of selling your Java knowledge for €150 an hour are ending.

For three decades, implementation knowledge was scarce, and that scarcity was the business model. Companies needed people who knew Java and Spring, relational databases, AWS or GCP, Kubernetes, CI/CD, whichever JavaScript framework was ascendant that year. That knowledge was expensive because it was hard to acquire, and a whole consultancy industry — ours included — sold it by the hour.

Generative AI attacks the scarcity, not the skill. Competent implementation is becoming dramatically cheaper. When one supplier needs four developers for three months and an AI-native team solves the same problem with two experienced engineers in a fraction of that, customers eventually notice. They were never buying Java hours. They were buying a solved problem.

That is not to say senior engineers have become worthless. I wrote in 2023 that ["the end of programming" was silly sales nonsense](/articles/the-end-of-programming-is-silly-sales-nonsense), and I still think so. What I underrated was how much the job itself would move.

**Code becomes cheap. Engineering judgement does not.** As implementation becomes abundant, value migrates to the questions that were always hard: What should we build, and what should we deliberately not build? Which architecture survives three years, and how does it integrate with the ERP nobody wants to touch? How do we migrate, secure and operate it? How do we recognise generated code that is subtly, plausibly wrong, or stop an agent inventing three abstraction layers for a CSV import — while keeping the result understandable to whoever is on call, and our best engineers out of a review queue ten thousand lines deep?

Read that list again: it is Brett's list. He named the central engineering problems of the AI era more precisely than most vendors selling into it. His conclusion is to stop using AI. Ours is better engineering around it.

Cheaper software usually means more software

One more point about cost.

When something becomes five times cheaper, buyers rarely buy the same quantity and bank the difference. They buy more. Projects that never cleared the business case suddenly clear it. The €500,000 internal application becomes a €75,000 project. The €150,000 integration becomes €25,000. The customer portal that died in three budget rounds is abruptly worth building.

The likely future isn't simply "fewer programmers". It is much cheaper software and far more of it — software that still has to be architected, secured, integrated and operated by people who know what they are doing. Economists call this the elasticity of software demand. Engineers can call it a bigger backlog.

This is the transition that pushed ZEN Software toward [AI-native software engineering and AI technology consultancy](/ai-solutions) — not a fresh label on the same hours, but because the work is genuinely different.

We help organisations work out where AI actually reduces development cost and where it merely hides it; how a team uses coding agents without drowning in review; what changes in [architecture, testing and delivery](/what-we-do/products-and-services/tech-consultancy) when much of your code arrives pre-written; how to [modernise what you already have](/what-we-do/products-and-services/new-software-project-modernisation) rather than blindly regenerating it. Above all: how lower implementation cost becomes [something the business can point at](/articles/reading-dora-metrics-when-ai-writes-half-your-commits).

Almost nobody needs more code. So: don't buy more code — build better software for less.

If you want to understand what AI-native engineering means for your software organisation, development costs or technology strategy, [talk to us](/contact). Bring a real problem rather than a demo request; it makes for a better conversation.

My Rusty Christmas: How Rust earned a place next to C++, Java, Python and Go (and made me argue with rust traits)

Pegboard met vijf gebruikte stukken gereedschap en een koperkleurige nieuwkomer met een eigen omtreklijn.

27-mijn-roestige-kerst-rust-naast-c-java-py.webp

Every few years, a new language earns a permanent place in your toolkit. Not because it’s fashionable. Not because the internet says you should. But because, at some point, you realise: “This actually solves problems I already have — even if it annoys me first.”
This Christmas, Rust joined that list for me.

Every few years, a new language earns a permanent place in your toolkit.      
Not because it’s fashionable.     
Not because the internet says you should.      
      
But because, at some point, you realise:      
> “This actually solves problems I already have — even if it annoys me first.”
        
This Christmas, Rust joined that list for me.

My background is pretty broad:
      
 

- ~10 years of C++ (systems, performance, RAII, undefined behaviour as lived experience)
      
- A lot of Java (enterprise, scale, long-lived systems)
      
- Plenty of Python (glue, speed of thought, experimentation)
      
- Some Go (services, pragmatism — the least of the four)
       
Rust had been circling my radar for years. I admired it conceptually, but like many C++ developers, I had the usual thought:      

> “This looks nice, but I already know how to do this safely.”
       
So this Christmas, I stopped theorising and just started to actually build.

What I expected:
      
- A steep learning curve
      
- Many compiler errors
      
- A lot of clever ideas wrapped in friction

      

What actually happened:
     
- A steep learning curve
    
- Many compiler errors
     
- …and a growing suspicion that the compiler was usually right
     
A very early example:

       
It felt like a very opinionated code reviewer who had seen all my old mistakes before.

In C++, this would compile and later explode.
       
Rust just says “no” — immediately, and for a good reason.
      
 

Rust didn’t feel like a new paradigm.

Ownership and borrowing: fewer lies, more honesty

The big shift was ownership and borrowing.

      

At first it feels restrictive.
    
Then it doesn’t feel very pleasant.
     
Then — slowly — it feels honest.

No more casual aliasing.
      
No more “this reference should be fine”.
     
No more mental bookkeeping about who frees what and when.

      

Coming from C++, this didn’t feel like losing power — it felt like **formalising discipline I already tried to apply manually**.

Rust’s error model clicked faster than expected.
       
- Errors are data
     
- Failure is explicit
      
- Control flow is visible

The ? operator alone deserves a small shrine.

        

It reads exactly like what it does:
        
> “If this fails, stop here — cleanly.”

 
       
After years of C++ exceptions and Go’s if err != nil, this felt like the grown-up version of both.

At some point during Christmas, I made the classic mistake.

 
      
I wanted to write a simple function that “just works for numbers”.

       
Python brain said:

At some point, I found myself staring at trait bounds thinking:

        

> “I have written template metaprogramming in C++.

> Why is this harder than I expected?”

        

This is where that Rust numeric meme hits painfully close to home.

        

If you want “numbers” in Rust, you don’t get a free abstraction.
       
You get:

       

- traits
       
- bounds
      
- associated types
     
- crates like num
       
And the creeping realisation that this is **deliberate**.

Then it clicked.
      
 

Rust isn’t bad at numeric abstraction.
      
It’s refusing to lie.

       

Python says:
      
> “I’ll figure it out at runtime.”

        

Rust says:
       
> “Tell me exactly what you mean, or don’t ship.”
      
 

So you end up writing:

Yes, that’s more explicit.
     
Yes, that’s more friction.

      

But it also means:
     
- no silent truncation
     
- no implicit widening
      
- no platform-dependent behaviour
     
- no “this worked in tests but not in production” math bugs

      

I didn’t enjoy that realisation in the moment.
     
But I respected it.

Undefined Behaviour (UB), now with fences

After enough years in C++, you don’t fear crashes.
      
You fear the **bugs that only show up in production**.

 
       
Rust’s stance on UB is refreshingly blunt:

Yes, UB exists.
     
No, you don’t get it accidentally.
      
If you want it, you must **opt in explicitly**.

        

That changes how you think about boundaries — and about trust.

Async without a GC (still slightly magical)

Async Rust deserves its own article, but briefly:

- async/await without a garbage collector
      
- Futures as explicit state machines
     
- No runtime hiding memory costs

       

Yes, the borrow checker gets louder here.
     
Yes, you sometimes have to restructure code.

      

But the result is predictable **performance with compile-time safety**, which is still rare.

The real signal wasn’t intellectual.

       

This didn’t stay a holiday experiment.
     
Before Christmas was over, I was already **using Rust in a ZEN Software project** — not as a rewrite for fun, but where Rust’s strengths actually fit:
      
- correctness
     
- performance
      
- long-term maintainability

       

That’s usually the moment a language stops being interesting and starts being **useful**.

I don’t think in terms of replacement.
      
 

For me, it now looks like this:
     
1. **Java**→ stability, scale, predictability
      
2. **Python**→ speed of thought, experimentation
      
3. **Rust → correctness under constraints, without giving up performance**
      
4. **Go**→ pragmatic services
       
5. **C++** → ultimate control, legacy ecosystems, sharp edges
      
Rust didn’t make me feel less experienced. It made me feel like my experience finally had a compiler that backed me up — **even when it annoyed me**.

I didn’t “switch” to Rust this Christmas.
     
I **added it**.

      

Yes, I argued with traits.
     
Yes, I cursed numeric bounds.
      
Yes, I lost a few hours to the borrow checker.

      

But the result stuck.
    
2026 is going to be a bit more Rusty.
     
And I’m genuinely looking forward to it. :crab:

Why I Keep Coming Back to Games: Two Books for the Beach (or Poolside)

Sunglasses resting on an open book beside a pool with clear blue water in the background.

vision-care-azure-goggles-water-sunglasses-eyewear-body-of-water-aqua

Summer 2025 Poolside reading: must-read books about working in game development




My reason for being in the software industry has always been games. I may never have made it to a game studio or launched a hit title. Still, the spark started early: XT-PC, Gameboy, 386 DX, Cyrix-powered Pentium, Voodoo 3D, and countless consoles—each generation brought a new obsession. And like many devs, I once dreamt of contributing to the kind of immersive, world-building magic that made childhood (and late-night college procrastination) so memorable.
     
Instead, I ended up in telecom, finance, and e-commerce. Not exactly AAA studios. The closest I came to game development? A lovingly-crafted Tetris clone I built in the ’90s with glorious SVGA graphics and keyboard controls that would make your wrists hurt today :sweat_smile:.
     
Still, I keep circling back—if not to making games, then to reading about how they’re made. And after [Blood, Sweat & Pixels](https://www.bol.com/nl/nl/p/blood-sweat-and-pixels/9200000073309239/) and [Masters of Doom](https://www.bol.com/nl/nl/p/masters-of-doom/1001004002075272), two books stood out this year for my summer reading list:

:video_game: Press Reset  by Jason Schreier

Following up on *Blood, Sweat & Pixels*, Jason Schreier returns with another behind-the-scenes tour of the gaming industry—only this time, it’s about what happens after the credits roll. Or don’t.

[Press Reset](https://www.bol.com/nl/nl/p/press-reset/9300000010138640) dives into the lives of the people who make games when their studios shut down, their jobs vanish, and their careers get reshuffled by mergers, cancellations, or creative implosions. It’s a sobering look at the lack of stability in an industry many of us dreamed of joining, told with Schreier’s signature blend of empathy and journalistic grit.

Stories from big names like Irrational Games (BioShock) and the systemic chaos at places like 38 Studios paint a picture that’s both fascinating and frustrating. If Blood, Sweat & Pixels was a love letter to the effort of shipping a game, Press Reset is a bittersweet reminder of what it costs—and how fragile it all is.
      
You walk away appreciating the craft **and** the chaos. And you may silently thank your past self for not packing up and moving to San Francisco with stars in your eyes.

:joystick: Disrupting the Game  by Reggie Fils-Aimé

Where Schreier gives you the journalist’s eye on the trenches, [Disrupting the Game](https://www.bol.com/nl/nl/p/disrupting-the-game/9300000043656149/) is Reggie’s executive-level power play. And it’s a surprisingly heartfelt one.
      
Reggie Fils-Aimé, the larger-than-life former President of Nintendo of America, shares his journey from being a Haitian-American kid in the Bronx to becoming the face of Nintendo for millions of gamers. Part memoir, part business book, this one is a different kind of game dev story—it’s about the why, not just the **how**.


      
You’ll find insights on leadership, disruption, and how to stay true to your values when managing one of the world’s most beloved entertainment brands. Reggie doesn’t sugarcoat the tough calls or corporate tension, but he also brings joy and pride into the narrative—two things that remind you what the best games are really about.

And yes, there’s enough inside baseball to satisfy your inner Nintendo nerd (spoiler: the Wii almost didn’t happen the way it did).

So while my number-of-games-developed is still sitting at **one** (28 years ago and counting), these books scratch the itch.
     
They show the ups and downs, the inspiration and heartbreak, and the real lives behind the pixels and press releases. Whether you’re lounging by the pool or between Git commits, Press Reset and Disrupting the Game offer something rarer than loot boxes—perspective.
      
Maybe it’s time to open my IDE again. I know I’ve got a few more lines of game code left in me yet.

Google recertification

Go Cloud Native, Go Big

Contact Form

Read more:

The $100 billion product demo failure: Google’s BARD

Google recertification

ZEN Software is now Google Cloud Partner!

Code is getting cheap. Engineering isn't.

My Rusty Christmas: How Rust earned a place next to C++, Java, Python and Go (and made me argue with rust traits)

Why I Keep Coming Back to Games: Two Books for the Beach (or Poolside)

Subscribe to ZEN Software's newsletter