Software Engineering Completeness : Knowing when you are done and why it matters

Whether creating new features or fixing bugs, what does Done 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 primitive approaches to delivering change and marking it as complete can lead to unwieldy code bases that are difficult to manage and foment technical debt.

Being done should 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, refactoring solutions as better thinking emerges ?

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 with the bottom level equating to unsustainable hacking of a codebase up through tiered levels of engineering practice with the apex representing Excellence in Engineering.

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.