The Lost Feed

🔬Weird Science

Inside the Hidden Debate: Who Really Writes Terraform Code?

Discover the surprising truth behind who writes Terraform code in tech teams. It's not always who you think, and this debate impacts every project.

0 views·7 min read·Jul 22, 2026
“Who Should Write the Terraform?”

Ever wonder who really builds the digital foundations of the internet? We're talking about the invisible code that creates servers, databases, and networks. One of the most popular tools for this vital work is called Terraform. It allows teams to manage their cloud infrastructure using code, a practice known as Infrastructure as Code (IaC).

But there's a quiet debate happening in tech companies everywhere: *who should actually write the Terraform code?

  • It's a question many teams struggle with, and the answer can change everything about how a project runs, from speed to stability.

The Unspoken

Question in Tech Teams

Imagine a construction site. Who designs the building? An architect. Who actually lays the bricks and pours the concrete? Construction workers. In the world of software, especially with tools like Terraform, it's not always so clear-cut. Terraform is like the blueprint and the construction crew all rolled into one. It defines and builds the "infrastructure," which means the underlying computer systems and services that applications run on.

This leads to a big question that often goes unaddressed: should the people who write the application code (developers) also write the infrastructure code? Or should it be the operations teams, who usually manage these systems and keep them running? Many teams simply let this role evolve without a clear plan, leading to confusion and sometimes even conflict.

Why Does This Even Matter?

You might think, "As long as it gets done, who cares who does it?" But it matters a lot for several reasons. How Terraform is written, and by whom, directly affects how fast new features can be launched, how stable and secure systems are, and even how happy team members are with their work. When roles are unclear, mistakes happen more often, and fixing them can take valuable time.

It also impacts the quality of the infrastructure itself. If the wrong people are writing it, or if there's no clear ownership and review process, the systems can become messy, inefficient, and hard to manage. This "technical debt" can slow down future development, increase operational costs, and make fixing urgent problems much harder later on. Clear ownership prevents these costly issues.

The Case for Developers to Write Terraform

Some in the tech world argue that developers are the perfect people to write Terraform. They have a deep understanding of exactly what their applications need to function correctly. They know if they require a specific type of database, a particular network setup, or unique security permissions. Giving them direct control means they can quickly create the precise infrastructure their code requires.

This approach often allows development teams to move much faster. Developers don't have to wait for another team to build or modify something for them. They can create the infrastructure themselves, test it alongside their application code, and deploy it all at once. This idea is a core principle of "DevOps," where development and operations work closely together to streamline the entire software delivery process. It empowers developers to be more self-sufficient.

"When I can write the Terraform for my application, I don't have to explain my needs to someone else and wait. It just gets done, and it's exactly what my code requires to run perfectly."

The Argument for Operations Teams

On the other side, many argue that operations teams are the true experts for writing and managing Terraform. These are the professionals who keep the systems running 24/

  1. They possess a deep understanding of security best practices, network architecture, and how to build highly reliable and scalable systems. They are trained to anticipate potential pitfalls and know how to avoid them before they become major problems.

Operations teams often have a broader, holistic view of all the infrastructure across an organization. They can ensure consistency, enforce company-wide standards, and optimize resource usage across many different projects. Their focus is on the long-term health, maintenance, and cost-efficiency of the entire digital environment, not just the immediate needs of a single application. They act as the guardians of the overall digital ecosystem.

Understanding the "Ops" Mindset

Operations professionals are inherently trained to prioritize stability, security, and cost efficiency. They frequently manage significant budgets for cloud services and are responsible for making sure resources are used wisely to avoid unnecessary expenses. Letting them write Terraform ensures these critical aspects are always a top priority from the very beginning. They play a key role in preventing systems from becoming fragmented, insecure, or overly expensive.

When Everyone Tries to Write It (The Hybrid Trap)

Sometimes, teams try to have both developers and operations write Terraform without a clear plan, roles, or review processes. This "hybrid" approach, while seemingly collaborative, can quickly become a messy and inefficient way to work. Imagine two different architects designing parts of the same house without talking to each other about the overall vision. You might end up with doors that lead nowhere, mismatched aesthetics, or a roof that doesn't quite fit the foundation.

Problems that commonly arise from this lack of clear ownership and process include:

  • Inconsistent setups: Different teams might use varied, incompatible ways to set up similar pieces of infrastructure, leading to confusion.

  • Security holes: Without a central review or standardized practices, critical security best practices might be overlooked or missed.

  • Confusion over ownership: No one is quite sure who is ultimately responsible for what specific piece of infrastructure, making troubleshooting difficult.

  • Slowdowns and conflicts: More time is often spent fixing conflicts, merging incompatible code, or debating approaches than on building new, valuable features.

This lack of clear ownership and process can lead to "infrastructure drift," where the actual deployed setup no longer matches what the Terraform code says it should be. It's a common and costly trap for growing tech companies.

Finding the Right Balance for Your Team

So, what's the best way to decide who writes Terraform? There's no single perfect answer that fits every company or team. The ideal approach largely depends on the team's size, the existing skill sets of its members, and how mature their development and operations processes already are. Many successful organizations use a shared ownership model, but crucially, they implement it with very clear guidelines and responsibilities.

Here are some common and effective approaches:

  1. Ops-led, Dev-contributed: Operations teams (or a dedicated infrastructure team) set up the core framework, modules, and governance rules for all Terraform. Developers can then propose changes or add new, application-specific resources within that established framework. All changes are typically reviewed by operations, ensuring consistency and security.

  2. Dedicated Infrastructure Team: A separate, specialized team focuses solely on creating, maintaining, and evolving the infrastructure. This team acts as the expert hub for all Terraform work, serving both developers and operations. They provide internal tools and services to other teams.

  3. Cross-functional Training and Pairing: Both developers and operations professionals receive training to understand enough about each other's roles and responsibilities. This might involve "pairing" (two people working on one task) to write Terraform together, sharing knowledge and building a common understanding.

The key to any successful model is open communication, mutual respect, and clear guidelines. Everyone on the team needs to know their specific role and responsibilities regarding infrastructure code.

Beyond Just Writing:

Owning the Infrastructure

Ultimately, the question isn't just about who types the Terraform code into a file. It's about who truly *owns

  • the infrastructure. Who is responsible when something inevitably goes wrong? Who ensures it remains secure, compliant with regulations, and cost-effective over its lifespan? This broader sense of ownership is far more important than the simple act of writing the initial code.

Teams that thrive understand that infrastructure is a shared responsibility, even if only one group does most of the typing. It requires a culture where everyone respects the needs and expertise of others and works together towards a stable, efficient, and secure digital environment. The goal should never be to point fingers, but to collaborate effectively to build better systems that serve the entire organization.

The debate over who writes Terraform code is a quiet but profoundly important one in the tech world. It highlights the constant challenge of bringing together different skills, perspectives, and priorities to build robust and reliable digital systems. By openly discussing the different viewpoints and establishing a clear, collaborative approach, companies can build stronger, more resilient foundations for their future. It's a critical conversation worth having, because the answer shapes the very backbone of our modern digital lives.

How does this make you feel?

Comments

0/2000

Loading comments...