BLOG
Production-Ready vs Feature-Complete: What’s the Difference?
“Production-ready” and “feature-complete” are terms that get used frequently in software development. To a software engineering team, these terms have drastically different meanings that may not be obvious to the casual observer. To understand the difference, we’ll first dig into the details of a software project lifecycle.
The Lifecycle of a Software Project
The lifecycle of a project begins with some sort of “discovery” process, where the software team works with the product owner to clarify their definitions of success, and gain an understanding of business priorities for the product owner. The outcome of this phase is often a list of project deliverables (features) and an estimate of the time that it will take to complete the project.
Fast forward, and the features are grouped into releases, which constitute useful functional groupings. For instance, a first release might include core workflow features around user account creation and management, as well as a few of the most important features of the proposed product. Over several releases, the project will reach a state where the client feels it is providing the value they desire. At this point, it will be transitioned to some sort of support and maintenance mode.
These two phases are ubiquitous in all software projects regardless of development style, but what differs greatly across development styles is the timing or cadence with which these phases are executed. The Agile development methodology (practiced at Very), states that these phases should happen frequently and in an iterative fashion. Iteration is a key component of Agile development, and in order to iterate, something must exist in the first place (we’ll come back to this).
Feature-Complete
For a piece of software to be considered “feature-complete,” it has all of its planned or primary features implemented but isn’t yet “final” due to bugs, stability or performance issues. On the surface, this seems reasonable, but in reality, it is ambiguous and subjective. This is rooted in the subject of the definition – “piece of software.” How “big” is this piece of software? How many features? How many man-hours?
As the piece of software gets bigger, becoming “feature-complete” becomes a daunting task. Simply receiving sign-off of “feature-completeness” may take weeks or months. The bugs and other issues that need resolution in order to push past feature-complete may be overwhelming. Worst of all – what if the team has spent so long focusing on checking off all the “planned or primary features,” that they are no longer relevant to the end goal of the project?
On the other hand, if the size of the “piece of software” is relatively small, most of the aforementioned problems vanish. If we focus the assessment of “feature-completeness” on small releases, we can easily check off the boxes, squash bugs quickly, and plan the next release with knowledge gained from the previous one. This allows for painless removal or modification of features as we learn more about their relevance to the overall project goals.
Production-Ready
A piece of software is considered production-ready if it is capable of meeting the demands of its users. This includes ease of usability, reliability, and availability. Various software teams assess these criteria in different ways, but Agile teams lean on acceptance of user stories in order to validate usability, and automated testing to validate reliability. The last piece, availability, means that the software must be available to use (e.g. it must be in production). Agile teams maximize availability by leveraging automated deployments and practicing continuous delivery.
Similar to the conundrum of “feature-complete,” assessing whether or not a piece of software is “production-ready” greatly depends on the size of that piece of software. If we make the assessment on a small piece of software (i.e. a small release), it is easy to perform. This means that it can be quickly deployed, and provide immediate value. Subsequent releases can be evaluated in the same way, ensuring every part of the software system is production-ready with minimal delay for QA/testing/etc.
What to Do With This New Information
People invest in a custom software development project because they believe it will bring them some positive return on their investment. Therefore, we should seek to take actions that will maximize the likelihood that a software project will yield a positive return. Some things that you can take away from the previous discussions are:
- Software cannot yield returns unless it is available in production, and these returns will likely be higher if the software is usable and reliable.
- Our knowledge of which features yield the highest return can evolve dramatically as users interact with software in production.
With this in mind, Very’s official recommendation is: “Focus on small, production-ready releases. Only assess feature-completeness within the context of each release. Embrace change in feature scope as you learn which features are most valuable.”
