Completion as Strategy
The case against perpetual iteration and for the radical act of finishing.
There is a pathology in modern software development: the belief that nothing should ever be finished.
Iteration is treated as virtue. Shipping a “minimum viable” version is celebrated not as a starting point but as the destination. The backlog grows. The polish never arrives. The system works, technically, but never coheres.
The cost of not finishing
Unfinished systems accumulate debt in ways that backlogs cannot track. Users develop workarounds. Teams build assumptions around limitations that were supposed to be temporary. The cost of completing the work later exceeds the cost of doing it now — but the cost is invisible, so it is never approved.
What completion actually means
Completion does not mean perfection. It means the system does what it claims to do, fully, without caveats that the user must discover on their own.
A completed system has:
- Error states that are handled, not deferred
- Documentation that reflects the actual behavior
- Edges that have been considered, not just the center
This is not a radical standard. It is the minimum that used to be expected.