Software Engineering Completeness
summary
Defines a concrete “done” as not just merged but deployed everywhere in production, with acceptance criteria (Given‑When‑Then), dates for start and finish, contingency buffers, and test automation across unit/integration/end‑to‑end. Builds a Maslow‑style pyramid from development → refactoring/decommissioning → reliability/observability → business alignment, prescribes tech‑debt tracking and quarterly debt sprints, feature flag enablement and feature flag removal, capacity planning and intentional technical debt with planned remediation.
AI-written summary · about
chapters (25)
- 0:00Introduction
- 1:51Defining done
- 4:42Business value of incremental delivery
- 7:51Types of production changes
- 10:16Acceptance criteria importance
- 14:06Problem complexity categories
- 15:52Project scope and creep
- 17:38Challenge of time estimates
- 21:51Breaking changes into deliverables
- 25:02From vague to concrete outcomes
- 26:53Dev done vs deployment done
- 30:46Feature flags in production
- 33:12Survival not enough for code
- 34:15Code health basics
- 37:25Refactoring necessity
- 40:57Technical debt understanding
- 46:40Tracking and preventing debt
- 50:52Importance of comprehensive testing
- 54:02System reliability fundamentals
- 1:00:36Improvement planning
- 1:01:38Architectural redesign
- 1:05:49Engineering-business alignment
- 1:08:39Roadmap meetings
- 1:11:48Visionary status in engineering
- 1:14:15When truly done
related talks
01h 01mSoftware Engineering Completeness
01h 29mSoftware Engineering Completeness - Knowing When You Are Done and Why It Matters
01h 10mSoftware Engineering Completeness
37mEngineering for Software
45mTaking Back "Software Engineering"
43mCode quality as an engine of your IT business
29mBuilding alignment with Eng & Product
32mSynergy: Building Strong Engineering Teams