---
name: software-engineering
description: Use when asked to explain software engineering as a general discipline — the engineering practices, processes, and principles applied to building software systems — as distinct from software-engineering-guide (a specific named published guide) and software-engineering-body-of-knowledge (SWEBOK, a specific named standard).
---

# Software Engineering

Software engineering is the discipline of applying engineering
principles — systematic, disciplined, measurable approaches — to the
design, development, testing, deployment, and maintenance of software
systems. It sits alongside, and draws on, computer science but is
distinctly concerned with building working, maintainable systems under
real-world constraints of cost, time, team, and changing requirements.

## Core concerns

- **Requirements** — understanding what a system needs to do and for
  whom (see [[functional-specification]]).
- **Design** — structuring a system before or while building it (see
  [[software-architecture]]).
- **Construction** — writing, reviewing, and refactoring code (see
  [[refactoring]], [[pair-programming]]).
- **Verification** — testing that the system does what it's meant to
  (see [[test-driven-development]], [[behavior-driven-development]]).
- **Process** — the lifecycle and methodology a team follows to go from
  idea to shipped, maintained software (see
  [[software-development-life-cycle]], [[scrum]],
  [[kanban]]).
- **Measurement** — assessing how well the above is actually going (see
  [[software-engineering-metrics]]).

## Distinguishing this collection's closely-named skills

This collection deliberately separates the *general discipline* from two
more specific, named things that share overlapping vocabulary:

- **[[software-engineering-guide]]** — grounded in a specific
  published reference (the Software Engineering Guide), useful for
  consulting concrete, opinionated best-practice guidance chapter by
  chapter.
- **[[software-engineering-body-of-knowledge]]** — grounded in
  SWEBOK, a specific formal standard defining the discipline's
  recognized knowledge areas.

This skill, by contrast, is the general-purpose entry point when the
question is about the discipline itself rather than what one particular
guide or standard says about it.

## Common pitfalls

- **Treating "software engineering" as synonymous with "coding"** — the
  discipline spans requirements, design, verification, and process, not
  just the act of writing code.
- **Applying heavyweight process to every project regardless of size** —
  software engineering rigor should scale with a project's actual risk
  and complexity, not be applied uniformly regardless of context.
- **Ignoring measurement** — proceeding without any sense of whether
  quality, velocity, or reliability is actually improving makes it hard
  to know whether process changes are helping.
- **Conflating this general discipline with one specific guide or
  standard** — see the distinctions above; citing "software engineering
  best practice" without being clear which source is meant can produce
  unfalsifiable or overly specific claims.

## Learn more

- [[software-architecture]] for the design-level subset of this discipline.
- [[software-engineering-guide]] for a specific, consultable published guide.
- [[software-engineering-body-of-knowledge]] for the formal SWEBOK standard.
- [[software-engineering-metrics]] for measuring engineering process and outcomes.