Software Engineering Completeness
summary
Argues that “done” means code is deployed and active everywhere and user-accessible, not just checked in; uses Gherkin-style given/when/then acceptance criteria, feature flags and staged rollouts, unit/integration/system testing, monitoring and instrumentation, and tracked tech-debt items. Claims 10 planned features with none deployed equals 0% done until in users' hands. Describes a Linux migration + QA team that cuts observed latency by ~50% and advocates automated feature-flag removal and scheduled refactor sprints.
AI-written summary · about
chapters (13)
- 0:00Introduction and talk overview
- 2:17What does done really mean
- 13:50Problem domains and complexity
- 17:03Project scope and time specificity
- 23:49Commitment and acceptance criteria
- 29:31Code completeness pyramid introduction
- 35:54Code health basics and decommissioning
- 41:16Technical debt and its management
- 47:15Testing pillars and quality
- 50:26System reliability and observability
- 54:17Strategic vision and long-term planning
- 58:08Business alignment and roadmaps
- 1:03:26Recap and final thoughts
related talks
01h 17mSoftware Engineering Completeness
01h 01mSoftware Engineering Completeness
01h 29mSoftware Engineering Completeness - Knowing When You Are Done and Why It Matters
33mSoftware development practices for companies that want to make an impact
57mEngineering for Software
43mCode quality as an engine of your IT business
33mThe Holy Grail in Scrum: The Done Increment
37mEngineering for Software