GoodEnoughIsNotGoodEnough is the belief by some that a solution to a problem which is merely ''adequate'', as opposed to outstanding, excellent or perfect, should be considered a failure rather than a success.  In the engineering context, this means that we should design a solution to meet some internally-imposed requirement for intrinsic goodness, above and beyond (or in some cases, instead of) what the customer wants.  (The corollary to this is the assumption, often stated sharply, that engineers who do indulge in GoodEnough are poor practitioners and are not upholding their professional obligation to DoGood.  Others make a similar argument in reverse--that any amount of over-design is a form of malpractice).

In many cases this is an AntiPattern (or a force leading to AntiPattern''''''s) as it is a common cause of FeatureCreep, GoldPlating, ArmorPlating, and other activities which some engineers love to do but which don't add much in the way of CustomerValue.

Of course, whether GoodEnough is GoodEnough depends on the definition of GoodEnough.  Many projects have failed because GoodEnough ''wasn't'' GoodEnough; in other words, the requirements missed the mark.  But in many other cases, a product which was better than GoodEnough failed when a GoodEnough competitor was available sooner or cheaper. 
----
I believe that one needs to clarify some definitions first.  There are many attributes to software that can be considered adequate or not good enough.  One can be referring to the functionality, the code structure, the responsiveness, the memory utilization, and many other qualities.

Code structure can always be improved and we have an excellent method to do this, refactoring.  As a supervisor, though, I recognize that some developers would be happy spending the rest of their careers refactoring code to make it clearer.  Some sort of subjective evaluation of "good enough" is required so that one can stop refactoring code and go on to something else.

Code functionality can always be increased.  I lean towards the approach that one only implements the minimal functionality as understood by the programmers as being required.  Again, this is subjective.  Some developers delight in finding short-comings in code concerning rare conditions or possible operations, especially in the code of others.  Other developers will defend non-handling of certain conditions as unnecessary, especially in their own code.  Although test cases are a good mechanism for specifying what is in the code, it is a subjective decision to decide what should be and what should not be in the code.

Other examples can be cited, but the point I am trying to make is that "Good Enough" is a highly subjective evaluation made by lots of different criteria.  Different people will have different interpretations.  If all parties accept this and listen to each other's evaluations, a consensus on good enough can be reached.  Too often, however, the decision gets pushed up to the supervisor where, based on biased information received and perhaps lack of time, an arbitrary decision is made just to stop the bickering.

--WayneMack [A software development supervisor who has just had a rough week of resolving silly disputes over good enough]

''But this is why I still argue that we need to PutaNumberOnIt. -- MartySchrader''
----
See also: WorseIsBetter, TheBestIsTheEnemyOfTheGood