A commonly encountered arrangement of opposing forces is one where cost is proportional to benefit. In other words, cost rises as benefit rises.
One way to solve this type of problem is to define a desired minimum benefit, and strive to achieve but only achieve this minimum benefit. We can call this a MorePainMoreGainSolution.
Examples
DoTheSimplestThingThatCouldPossiblyWork YouArentGonnaNeedIt
See Also
GoldilocksSolution LessIsBetterSolution BinarySolution
Is there a name for when 100% is significantly better than anything less? This is being claimed for XP as a whole, and there are other examples. Eg if something works 99.5% of the time, you still need the overhead of checking it, and the cost of checking for rare events may be as high as for common ones. If it works 100%, you can eliminate the checks. -- DaveHarris
GO/NOGO? Btw, eXtremists believe that there is a popping effect with "all" the practices in place, that gives an extra kick to productivity. It's not particularly magic (if it's true), it's just a curve that arcs upward, like any power of N > 1. I'm not sure what the checking notion is: I'm not aware of anything in the material universe that CANNOT fail. --RonJeffries
Think guaranteed algorithm vs a heuristic.
I've had this go both ways.
Sometimes a guaranteed algorithm fails, usually because the primitives it uses break. For example, someone changes a database column type to be case-insensitive, or the algorithm uses floating point and doesn't take enough care about accumulated errors. In both of these cases, treating the algorithm as heuristic would have resulted in better run-time behavior. If you expect that some code will never fail, your failure behavior may be unexpectedly bad!
I was also in a design discussion where it was proposed that we "not let power fail". The idea was to make the power delivery system sufficient redundant (through e.g. fine-granularity UPS near or embedded in each component) that catastrophic power loss was deemed "impossible". The software design would have become much simpler, but wow! what an assumption to make. --GarthDickie