Software Engineering

Software engineering is the discipline that organizes everything the previous seventeen topics covered into a repeatable process, and this entire curriculum series is itself a real example of that process running end to end. Requirements come first: before any code gets written, someone has to decide exactly what the software needs to do, the same decomposition discipline the computational-thinking topic introduced early in this series, just applied to an entire project instead of one problem — this series itself started from a requirements list handed down up front, a specific 28-topic order plus a companion list of project ideas. Modular design breaks the resulting system into independent, reusable pieces rather than one giant tangle of code, the same instinct behind choosing the right data structure or the right programming paradigm earlier in this series: this entire project reuses one small, unmodified deploy script across every single topic rather than writing a new one-off insert script each time, because a tested, working module is more valuable copied than rewritten. Version control tracks every change over time so any single change can be inspected, compared, or reverted without threatening the rest of the system; this series' own deploy process takes an automatic timestamped backup of every single insert before committing it, the exact same instinct behind `git`'s commit history, just scoped to one database row instead of an entire codebase. Testing is the debugging-and-testing topic's assertions and test cases scaled up from one function to an entire release: before any topic in this series gets deployed, its content passes a fixed checklist — valid JSON, zero stray backslashes, no elements overflowing their intended width, no internal identifiers leaking into reader-facing text — and two topics in this very series were caught and fixed by exactly that checklist before they ever reached a live reader. Maintenance is what happens after something ships: bugs discovered in production get fixed, lessons learned get written down so the same mistake isn't repeated, and a system keeps evolving rather than freezing the moment it first works — this series' own tracking file has grown a running list of exactly these lessons, from a backslash gotcha in an early topic to the overflow-audit fix two topics ago, each one folded back into how every later topic gets built. None of these five practices is optional once a project grows past a single script a single person runs once; they are what separates software that keeps working as it grows from software that quietly rots, and the next topic, theory of computation, steps back from engineering practice entirely to ask a more fundamental question: what can any program, built with any amount of engineering discipline, actually compute at all.