By Peter Muldoon
Whether creating new features, fixing bugs or looking at larger issues affecting a codebase, 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" involves aspects of software engineering that are "above the code" and 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 or refactoring cleaner solutions as better thinking on solutions emerges?
In this presentation, we will explore these topics and build up a Software Engineering Completeness pyramid for change delivery analogous to Maslow’s Hierarchy of Needs pyramid for human survival. This will 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 where qualitative shifts in perspective is required to future proof your application.
These levels in the pyramid directly translate to engineering competence and maturity in the field of software expertise and can help map what level of engineering accomplishment/proficiency do you aspire to?
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, creates happy consumers and allows for clean succinct communication to others of when you are actually and finally DONE.
Advertisement
