Someone asked me the other day what ‘feature complete’ meant. I replied that I felt it meant that everything you intended to put into the application is there and not missing. Other people gave other responses but it got me to thinking.
Here is the definition of ‘feature complete’ from Wikipedia:
A feature complete version of a software is not yet final, but contains all intended functionality of the final version.
Usually a feature complete software still has to undergo testing and bug fixing as well performance or stability enhancing before it can go to release candidate and finally gold status.
I think the semi-permanent beta status of open source and web software skews our expectations. We’re so used to the term ‘beta’ being applied to software we’ve really lowered our expectations of software. It used to be that software at the ‘alpha’ stage was feature complete but functionality could significantly change with usability testing. ‘Beta’ stage was when all functionality was complete and usability testing started, usually by allowing a bigger group to test it. Any bugs get fixed and a new beta version is released to make sure the bugs were fixed and no new bugs introduced.
Finally, the ‘Final Candidate’, or ‘Release Candidate’ was a fully functional version of the software that if everything worked properly it would be released to the public.
The Wikipedia definition for ‘Release Candidate’:
The term release candidate (RC) refers to a version with potential to be a final product, ready to release unless fatal bugs emerge. In this stage of product stabilization (read QA cycle), all product features have been designed, coded and tested through one or more Beta cycles with no known showstopper-class bug. When a version get to the Release Candidate cycle, only one iteration should be necessary.
Obviously, these definitions are fluid – at best. Problems discovered late in the beta stage could seriously affect functionality and certainly a major flaw discovered in a Final Candidate could (and should) push a public release back. If you have a ‘set in stone’ release date, however, how does that affect your releases? I imagine that it severely limits your flexibility if major problems are found – especially if you have some sort of contractual obligations to release.
Is this your understanding of the software process? Or is software now so complex and so fluid that we need lowered expectations of what software should be capable of doing for us? Is it okay to release with known bugs as long as it’s ‘good enough’?