Whether creating new features or fixing bugs in software applications or libraries, the question that inevitability gets asked is "Are we done implementing a change ?". But what does that mean in Software Engineering terms and what is its effect on delivering change in the real world ?
Being "Done" can mean just checking code into a repository but what about the merging of changes for a release, the updating of feature flags and the phased deployment of these changes into Production. Primitive approaches to delivering change and defining it as complete can lead to unwieldy code bases that are difficult to manage and foment technical debt.

However implementing change should go further than that and ask questions on the completeness of the changes. Has code quality/technical debt been addressed ? How does tactical fixes versus strategic direction achieve different versions of being finished. what about the vital task of decommissioning of old code as new code is added to replace it ?

This better line of thinking of "Being Done" will bring about a more maintainable and extensible codebase. But stopping there falls short of proper engineering goals. What about the Monitoring of system health, Holistic testing and strategic goals of the business ?

In this presentation, we will explore these topics and build up a Software Engineering Completeness pyramid for change delivery - analogous to the survival needs pyramid - and illustrate differing levels of being change complete.

The revelation that "doneness" - properly defined - and executed is a force that drives superior software engineering and strikes to the heart of achieving improved outcomes. This clarity of thinking on the real cost of software ownership promotes flexible software, happy consumers and allows for clean communication to others of when you are actually and finally DONE.