Recently, one of the devs in my team asked why I’m so obsessed with getting things into production. “Why can’t they stay in UAT for a while?” they said.

And I replied, “Code that isn’t in production is a liability. What we write only has value when it’s being used.” And then I’m like this deserves a blog post.

The Liability of Idle Code

Every line of code we write carries risk: conflicting logic, hidden bugs, security vulnerabilities, etc. Businesses are willing to pay our expensive developer salaries for these risks because, once in production, the potential return is exponential. A feature built in two weeks can reach millions of users.

But code only realizes its value when it’s solving real problems for real users. Even if it fails to meet expectations (as is often the case, in my experience), at least the business learns from actual feedback.

The Illusion of UAT

“But isn’t testing important?”

Of course. UAT, unit tests, and e2e tests are all crucial to getting code production-ready. However, UAT is not the real world; it’s a controlled environment. It’s easy to think everything is fine when all tests are green. But as soon as you hit “deploy”, reality kicks in, and all the world’s airports shutdown.

The longer code stays in UAT, the more undetected issues can accumulate. Frequent releases to production reduce this risk by isolating changes, making it easier to pinpoint and address problems as they arise.

CI/CD: Continuously Delivering Value

CI/CD isn’t about releasing perfect code on the first try. It’s about building a robust process for identifying and fixing issues quickly. It’s why we tolerate the complexity of modular architectures, feature toggles, and observability tools because they enable faster, safer delivery of value.

Idle code doesn’t help anyone. It’s only when we release it that it can start making a difference, solving problems, or teaching us what to improve.