Setting Realistic Goals in the SDLC Spectrum: When is Good Enough Good Enough?

The term good enough has many different meanings. Some define it as lack of follow through or initiative, while others view it as doing just enough to get by. When it comes to the Software Development Life Cycle (SDLC), it means setting realistic goals. Goals help project managers to define goals at each phase of the SDLC. Using the good enough threshold (is the work in this phase good enough to move on to the next?) keeps these goals on track. Good enough in SDLC maintains the appropriate balance between not enough effort and wasted effort in each of the development phases.


The SDLC is a process to plan, define, test and implement an information system. The approaches are defined and designed for use during the software development lifecycle process. These approaches are referred to as software development process models (such as the Agile, Waterfall, incremental, iterative, and V-models). Each follows a particular life cycle to ensure success by driving a defined set of activities through each phase of the model. Understanding a department or enterprise’s approach to SDLC reveals the sequence of activities required to complete the project.


When does an element reach good enough?

Deciding when a project activity reaches the good enough threshold depends on the context of the situation and weighed against the company’s competing demands and interests. It must strike a balance between the subjective and the objective view of the requirement’s priority. The objective quality component of your decision drives the need for a formalized system, allowing for uniform application of the test for priority while working within the constant constraints of an inbound timeline. Putting the question under the scrutiny of stakeholders and team members makes the question more objective because it is no longer a single source decision.


What is good enough during each phase of the SDLC?



Begin conversations about the good enough threshold in the planning stages. Consider the risk tolerance of the stakeholders in the project. Spending time on this issue during planning reveals reservations, providing visibility to hidden risks and building the framework for addressing good enough throughout the SDLC.



Before beginning to design, finalize the good enough threshold. Think about the project, the stakeholders, and the competition adjusting the threshold to meet the project demands. A good enough design doesn’t have to mean a rudimentary user interface. Instead, good enough may call for a design that delivers lots of features and a simple but rich user experience.



Developers live in a complex world where the client pushes for functionality that delivers without defects, and they want it yesterday! This can be hard to balance. Determine good enough by answering the following:


  • Will the code be understood 3 months from now?
  • Is the code free of duplication? Have any wheels been re-invented?
  • Is the code supported by unit testing?
  • Is the code base consistent in style and approach to solving problems?


There are situations where the quality standard should be higher, including fields like system performance, scalability, traceability, and error handling. The requirements in these areas may change from project to project. Readability, freedom from duplication, and unit tests are standard to all but the most trivial of systems. Ideally the code is 100% defect free from the moment it is checked in, but that is not always obtainable. The goal in the good enough approach to coding lies in maintaining long-term viability of the code base by being able to easily fix, improve, and/or extend it.



Successful software quality managers say, “It isn’t the number of bugs that matters, it’s the effect of each bug.” While most quality metrics focus on the number of defects per iteration, it is not the number of defects that matter, but the impact they have on expected functionality and your good enough threshold. Your good enough threshold in testing means you have removed all potentially defective known bugs. Windows 3.1 reportedly shipped with 5000 known bugs, yet the product was a smashing success.¹ Windows’ QA team chose the right bugs to ship with and the right functionality that impressed the end user.



Good enough in deployment centers around determining the approach, timing and resources required. Collaborate with IT and stakeholders to define “good enough” before deployment into a client facing environment begins. Do not enter deployment until you’ve determined all previously set goals (good enough thresholds) have been met. Carefully consider the good enough threshold in this phase: it should be decided by your progress in the predetermined schedule. Rushing the deployment phase or failing to consider the project as a whole could be detrimental.


There’s a point where it takes more and more energy to achieve smaller and smaller gains, putting in as much effort spent on a project so far to get a tiny 1% or 2% improvement. It’s important to consider the good enough principle in each stage of the SDLC. There are times when perfection is called for; yet logic requires that most of the time, good enough will do.


¹Yourdon, Ed, Rise & Resurrection of the American Programmer, 1996, p. 157


Leave a Reply

You must be logged in to post a comment.