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
AntiPatterns) 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