What Is Software Engineering?

The Conference That Named a Crisis

The year is 1968. A group of 50 computer scientists gathers in Garmisch, Germany, under NATO sponsorship. The agenda is alarming: software projects are failing everywhere. IBM's OS/360 operating system — the most ambitious software project ever attempted — consumed 5,000 programmers, cost $500 million, shipped years late, and still arrived riddled with bugs. Engineer Fred Brooks, who led OS/360, later wrote that managing the project was like fighting a monster that "takes years to slay."

The attendees coined a deliberately provocative phrase: software engineering. By calling it engineering, they were issuing a challenge — build software with the same rigour, discipline, and predictability that civil engineers use to build bridges that do not fall down.

Fifty-eight years later, the challenge is still very much alive.

---

The Software Crisis: What Went Wrong

The 1960s and early 1970s exposed a painful truth: writing code is not the same as building reliable software. Projects failed at every scale.

"The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem." — Edsger W. Dijkstra, 1972 Turing Award Lecture

The problem was not cleverness — the programmers were brilliant. The problem was process. No one had systematic methods for specifying what to build, tracking progress, managing complexity, or verifying correctness.

---

Software Engineering vs Programming

A common question: isn't software engineering just "fancy programming"? No. The difference is significant.

Programming is an activity inside software engineering, the way bricklaying is an activity inside architecture. Excellent programmers who lack engineering skills tend to produce code that works brilliantly today and is unmaintainable by next year.

---

Fred Brooks and the Mythical Man-Month

In 1975, Fred Brooks published "The Mythical Man-Month", drawing on his OS/360 experience. Its most famous insight, known as Brooks' Law:

"Adding manpower to a late software project makes it later."

Why? Because new team members need time to get up to speed, experienced members must train them, and communication overhead grows quadratically. If a team of 4 has 6 communication channels, a team of 10 has 45. Coordination costs swallow the added capacity.

Brooks also declared: "There is no silver bullet" — no single technology or technique will produce order-of-magnitude improvements in software productivity. Forty years later, this remains largely true.

---

When Software Fails, People Die

Software failures are not just inconvenient — they can be catastrophic. These cases shaped how the profession thinks about safety-critical systems.

---

The Four Attributes of Good Software

Software engineering researchers converged on four core quality attributes. Every architectural decision is ultimately a trade-off between them.

1. Functionality — Does it do what users need?

• Correctness, completeness, appropriateness

2. Reliability — Does it behave consistently without failure?

• Fault tolerance, recoverability, availability (Google targets 99.99% — that is 52 minutes of downtime per year)

3. Efficiency — Does it use resources wisely?

• Time performance, memory usage, energy consumption (Amazon found that every 100ms of latency costs 1% in sales)

4. Maintainability — Can it be changed without breaking?

• Analysability, changeability, testability (at Google, roughly 50% of engineering time is spent reading and understanding existing code, not writing new code)

---

The Software Development Lifecycle

Software engineering organises work into phases. The exact phases vary by methodology, but the core activities are universal.

• Requirements: Understand what stakeholders need (not just what they say they want)
• Design: Architecture, data models, interfaces, algorithms
• Implementation: Writing, reviewing, and integrating code
• Testing: Unit, integration, system, and acceptance testing
• Deployment: Releasing to production safely — CI/CD, feature flags, canary releases
• Maintenance: Bug fixes, performance improvements, new features — typically 60–80% of total software cost

---

Roles in a Modern Software Team

Building software at scale is a team sport. Netflix has hundreds of engineers working on a single streaming platform, each with a distinct role.

At startups, one person plays five of these roles. At Amazon, each role is a full specialisation with its own career ladder.

---

Why This Matters Now

The global software engineering market was valued at $429 billion in 2023 and is projected to exceed $1.5 trillion by 2032. Every industry — healthcare, finance, transportation, entertainment — is now a software business in disguise. The discipline that NATO attendees invented in 1968 to prevent the next OS/360 disaster is now the backbone of the global economy.

Understanding software engineering means understanding not just how to write code, but how to build systems that last, teams that function, and products that people trust.

---

Key Takeaways

• Software engineering emerged from the 1960s software crisis — a recognition that complex software requires rigour, process, and teamwork, not just coding skill.
• Brooks' Law: adding people to a late project makes it later, due to communication overhead.
• Real-world failures — Therac-25, Knight Capital, Boeing 737 MAX — show that poor engineering practices have life-and-death consequences.
• Good software has four attributes: functionality, reliability, efficiency, and maintainability.
• The SDLC provides a framework for organising the work, from requirements through maintenance.
• Software engineering is a team discipline — knowing your role and the roles around you is as important as knowing your programming language.