Is Software Engineering Dead?

Is Software Engineering Dead? A Statement of Experience

The most expensive mistake of my career wasn't a line of code; it was a "yes." Years ago, as a young systems engineer, the moment I said, "let's handle this with software," I inadvertently triggered the end of an era. Since then, with every new project, with every new wave of technology, the same question echoes within me: Is software engineering, as we know it, truly dead? Or has it merely evolved?

This isn't a topic to be dismissed with clichés like "modern systems are too complex" or "everyone's becoming a DevOps engineer." This is an honest assessment from someone who has spent 20 years in the field, someone who can see the forest through the trees, who has witnessed the transition from dusty server rooms to the infinite expanse of the cloud. In a world where every bug used to cost a sleepless night, and now a single API call can bring down entire systems, we need to understand where this profession is heading.

Why This Question on My Mind? A Pragmatic Perspective

It all began during the days when I was redesigning a manufacturing ERP system from end to end. We were working on a completely domestic and proprietary solution using a PostgreSQL database, a FastAPI backend, and a Vue.js frontend. AI-powered production planning, operator screens, supply chain integration via iSCSI... the list went on. In this project, I saw that software architecture was essentially about organizational flows. Purchase, produce, ship, invoice; perfecting all these business workflows with technology... And right at that point, software itself, the act of writing code, was just the tip of the iceberg.

ℹ️ The Priority of Organizational Flows

Software architecture is often not about choosing technology, but about the most accurate migration of business processes to the digital realm. In an ERP system, a "production planning" module should not only be about algorithms but directly linked to the factory's actual operations.

Then, I looked at my own projects and the consulting I've done. Financial calculators I developed on my own VPS, an Android spam blocker, even a data platform... All of them emerged to solve a problem, to meet a need. In these projects, writing code was just a tool. The real issue was deciding which technology to choose with the right trade-offs, how to scale the system, how to ensure its security, and most importantly, how to deliver value to the user. Software engineering is no longer just about writing code; it's the art of holistically analyzing a problem and producing pragmatic solutions.

New Sultans of the Old Bridge: System Administrator or Programmer?

I've been involved with system and network administration since 2006. Everything from local network architecture to firewall policies, VPNs to ZTNA, was familiar to me. Then I dove into the world of enterprise software development and realized that these two fields were much closer than I thought. As a system administrator, I would tweak database settings to optimize an application's performance. Like adjusting checkpoint_segments to resolve WAL bloat issues in PostgreSQL, or managing OOM (Out Of Memory) problems in Redis with eviction-policy. These were details that a programmer might not directly deal with but were vital for the application's operation.

💡 A Pragmatic Approach Matters

Details like creating more reliable scheduled tasks with Systemd timers instead of cron, preventing log spam with journald's rate-limit feature, or softly adjusting resource limits with cgroups are critically important for the overall health of the system.

These experiences taught me that software engineering isn't just "coding"; it requires the ability to delve into the depths of the system, understand the infrastructure, and foresee potential problems. To understand why an application was slow, one needed to examine not only its code but also the server's resources, network traffic, and database queries. This was an old-school systems engineer's perspective, challenging the modern "frontend-only" or "backend-only" divide.

Trade-offs and Real-World Challenges

There are always trade-offs in the world of software development. Monolith or microservices? Event sourcing or CQRS? Optimistic locking or pessimistic locking? These choices are not just technical preferences but decisions that shape the future of a project. When I was developing the backend for an e-commerce site years ago, we decided to further modularize the monolith structure to keep up with rapidly growing traffic. The operational complexity and communication costs of migrating to microservices seemed like a bigger risk to us at that moment.

⚠️ Be Aware of Trade-offs

Every technological choice has a price. Migrating to microservices can increase operational complexity, while maintaining a monolith structure can also slow down development speed over time. The important thing is to make these trade-offs consciously and find the solution that best fits the project's needs.

Decisions like these should be based on concrete experiences rather than a list of "best practices." For instance, while developing an ERP for a manufacturing company, I found it smarter to ensure the database planner created a more efficient query to solve the N+1 query problem, rather than forcing the ORM's capabilities. These are insights gained in the field that you won't easily find in textbooks. Learning from my own mistakes is also part of this process. Last month, I accidentally put a sleep 360 command in a script into an infinite loop, forcing the server to be OOM-killed. Moments like these make us more careful and less error-prone engineers.

Looking Ahead: Software Engineering Continues, But How?

Is software engineering dead? No. But it has definitely changed. It's no longer limited to just writing code. It requires understanding system architecture, mastering network protocols, thinking about security from the outset, and deeply grasping business processes. With the rise of AI, new areas like prompt engineering, RAG (Retrieval-Augmented Generation), and agent patterns are also being included in this picture. Using different providers like Gemini Flash, Groq, and OpenRouter with fallback mechanisms in my own projects is an indicator of the rapid evolution in this field.

The future of this profession lies in engineers who can integrate different disciplines, see problems holistically, and build bridges between technology and business processes. Those who not only write code but also design the system, ensure its security, and understand the core of the business will stand out.

So, what do you think? What are your observations about the future of software engineering? Share in the comments, and let's advance this discussion together.