You are never taught how to build quality software
Many engineers argue that computer science education and typical internships focus on algorithms and shipping features, while offering little systematic training in software quality, testing, and long‑term maintainability. Commenters contrast this with fields like aviation and manufacturing that embed rigorous QA and post‑mortem processes, but note that such practices are costly and often clash with business incentives to move fast. The debate centers on whether “quality” can be formally taught, how much can only be learned through experience, and how to justify QA work in organizations that primarily optimize for speed and short‑term results.
What “quality software” means (and whether it’s teachable)
- Many argue “quality” is vague: is it reliability, performance, maintainability, UX, or business value?
- Some say quality is mostly learned through practice and feedback, not classroom theory.
- Others insist there is an academic and engineering discipline (software engineering, QA, formal methods) that teaches quality, but it’s unevenly adopted.
Comparisons to other fields (aviation, manufacturing, engineering)
- Aviation and manufacturing are cited as examples where quality is systematically taught via checklists, regulation, incident reviews, and process controls.
- Some suggest a comparable 500‑item checklist for software would dramatically cut bugs but kill startup-style velocity.
- Counterpoint: even in “hard” engineering, defects, recalls, and failures are common; everything is “good enough,” not perfect.
University CS vs. Software Engineering
- Recurrent complaint: CS programs focus on algorithms, compilers, theory, and low‑level systems, but barely on QA, testing, debugging strategy, or large‑scale system design.
- Others report having taken serious software engineering courses: testing, SDLC, UML, team projects, capstones that simulate real-world maintenance.
- There’s debate over whether universities should be job training vs. pure education, especially given rising tuition and job expectations.
QA, testing, and process
- Strong theme: QA is often bolted on at the end (or skipped) due to schedule pressure; “QA sprints” and late testing are called out as anti‑patterns.
- Advocates push for: tests written alongside code, CI/CD, automation, snapshot/visual tests, coverage plus mutation/fuzz testing, and thoughtful metrics (with awareness of Goodhart’s law).
- Some note that high-quality shops exist where 40–60% of effort is testing and quality work, but they’re not the norm.
Bugs, “bug‑free” claims, and formal methods
- Consensus: absolute bug‑free software is practically unattainable beyond trivial programs; “zero bugs” is better seen as an asymptote or “no known defects against a spec.”
- Debate over definitions of “bug” (deviation from spec vs. any unexpected behavior) and whether spec errors count.
- Formal methods and proofs can eliminate classes of defects in safety‑critical domains, but are expensive, limited in scope, and don’t fix bad or incomplete specifications.
Economics, incentives, and tradeoffs
- Many point out management often prioritizes speed and visible features over quality because business metrics rarely reward long-term maintainability.
- Quality costs are diffuse and delayed (technical debt, slow teams, user time wasted), while development cost is immediate and measurable.
- Some argue that at large scale even “rare” bugs become common and cause “death by a thousand cuts,” but others claim most markets tolerate mediocre software if it ships fast and solves a problem.