There is No Such Thing as "JUST"

How often have you been in a meeting or received a request from a product manager or stakeholder, only to hear the word “just” thrown around?

“It’s just a quick fix, right?”
“Can’t you just change this small thing?”
“Isn’t it just a simple merge request?”

For those of us working behind the scenes, we know that there is no such thing as just. The reality is far more complex, especially when dealing with production systems that impact thousands or even millions of users, not to mention the potential risks to revenue or user experience.

Why There’s No “Just” in Production Systems

When people say “just,” they unintentionally oversimplify the work involved in making even minor changes. Whether it’s approving a merge request, backfilling data, or modifying a small aspect of a system, every action touches multiple components. Each step must be handled carefully to ensure nothing breaks, and this becomes even more critical when dealing with live production environments. One wrong move could lead to user downtime, data corruption, or even significant revenue losses.

What gets overlooked is the complexity that comes with making these “simple” requests. Stakeholders or product managers often fail to see the chain of processes that need to happen before a change can be safely implemented.

The Risk of Oversimplification

Let’s put it into perspective. Imagine a product manager asking you to “just backfill some data for a specific period.” On the surface, this sounds like a small, quick task. But in reality, you’re dealing with:

1. Data integrity: Ensuring the data you’re backfilling is accurate and won’t cause discrepancies in reports or user dashboards.
2. System performance: Running large data processes might slow down, hit custom limit on cloud warehouse, or even crash your production environment, affecting user experience and costing the company millions of dollars.
3. Testing: Every change, no matter how minor, needs to be thoroughly tested to ensure it doesn’t create unintended side effects.
4. Dependencies: The change could impact other services, downstream processes, or data pipelines, making things much more complicated than they initially seemed.

Suddenly, this “simple” task is now a high-risk operation, potentially spanning days of work and requiring multiple layers of testing and validation. I for one, I have had to do a backfill that span a week, this include refactoring the codebase and systematically pulling billions of records. A process that keeps hitting custom query limit, a feature I had no idea were in place.

The Reality of Engineering and Data Processes

In many cases, the steps required to implement these “just” requests can take hours, if not days. Here’s a glimpse of what typically happens in engineering or data teams:

1. Local testing: First, changes are made in a safe environment, and local tests are run to ensure everything works as expected.
2. Quality checks: Data quality is verified, and any potential issues are flagged before moving further.
3. Merge requests: The code changes are submitted for review, but that’s not the end. Another engineer reviews the code, and only after everyone is satisfied with the safety of the changes can it be merged.
4. Production deployment: Even after the code is merged, deploying to production involves running additional verification processes to make sure nothing breaks in the live environment.

Each of these steps takes time and effort, and none of them can be skipped. The risk of overlooking even one small issue could result in costly mistakes, or worse—a full system breakdown.

Examples of “Just” Gone Wrong

Consider this: a seemingly minor tweak to a pricing algorithm goes live, but due to poor data validation, the algorithm starts overcharging customers. A ride-hailing company experienced this firsthand when their system quoted double the actual fare. What started as a “small fix” led to significant customer backlash and revenue loss.

In another case, a major e-commerce company once lost millions because a “simple” request to backfill data corrupted an entire month’s worth of sales reports. The team had to scramble to fix the issue, but the damage had already been done—stakeholders lost trust in the data.

A Better Way to Think About These Requests

Rather than assuming something is “just” a quick fix, stakeholders and product managers need to understand the true scope of the work involved. Engineering and data processes are not just about writing code or clicking a button—they are about managing risk and ensuring the system remains stable.

So next time you hear the phrase, “Can’t you just do this?”, here are some questions you can ask in response:

• What are the potential risks to the system if we implement this change?
• Are there dependencies we need to consider before making this change?
• How will we test and verify the change before it goes live in production?
• What’s the rollback plan if something goes wrong? Yes, it always help to have fail safe.

These questions help shift the mindset from oversimplifying the task to appreciating the complexity involved.

Trusting the Process

In engineering, processes exist for a reason. They ensure quality and reduce risk, especially in high-stakes environments like production systems. If your team doesn’t have robust processes for testing, quality checks, and approval workflows, then there’s a fundamental issue that needs to be addressed. Skipping these processes in the name of speed only increases the likelihood of catastrophic failures down the line.

To sum things up; when it comes to production systems and data, there’s no such thing as just a simple fix. Every change has a ripple effect, and with that comes responsibility. It’s easy to dismiss these tasks as small, but the reality is far from simple. The next time you hear someone say “just,” take a moment to unpack what’s really involved and ensure that all steps are taken to mitigate the risks.

So ask yourself, Is it ever really just a change? Because in production, there’s no room for shortcuts.