Just when is it good enough?

In theory, software development is precise.  Some even argue it's a kind of engineering.  After all it's just ones and zeros ... processor gates and electrons.  Personally, I disagree.

Software is an ethereal manifestation built by people for people.  It's barely bound by the laws of nature and rarely if ever viewed by any 2 people the same way.  Even those who truly understand how it’s made rarely agree on how it should work.

Consider the simple requirement; “Add two numbers and return the result.”
Child's play right?  Computing power is clearly purpose built to do math.  So just what does it take, what do we need to understand to be good enough to call this one, very simple requirement, done? 

A little decomposition is in order.

Add.
A quick internet search on 'Add' returns nothing about math in the first dozen entries.  Both Bing and Google think a request to understand Attention deficit disorder is more likely than someone trying to understand this simple mathematical term.  Dictionary.com has 4 possible verb definitions and the first has two 'or' statements.  Seems the meaning of Add isn't so clear.  Darn ambiguous English.  Let's run with "to find the sum of" for now.

Two numbers.
Oh yes, another trap.  Is this any two numbers?  Can we allow 5 and VI to be summed to 11?  Will they be constrained to whole numbers? Will 4.967832 be okay or should it be rounded to 5?  What about 4 1/3 or Pi?  Convert to decimal and round first or after summing?    Is there any additional requirement to validate the two numbers individually, or as a pair?  Are these numbers abstract or maybe representing reference numbers of a known set?  Something like classic library reference numbers from the Dewey decimal system.  They went from 000 to 900 with 2 places of precision following the main classification.  So numbers above 999 would be inappropriate.

And.
Let's face it.  Good requirements shouldn't be compound statements.
Is this a condition of success?  Would correctly solving the mathematical expression without returning be another form of, or maybe a partial, success?

Return.
Although common parlance among technical types, return is no more precise than the rest of the requirement.  Return to where?  A function can return to its caller without ever leaving volatile memory.  Display is implied but where isn't clear. Should it be on screen or on paper via a printer?  Does it need to be placed somewhere specific on the screen such as a labeled field?  And does it need to be in a specific state, say available to the system clipboard?

The result.
Not to put too fine a point on it but 'the' certainly requires a singular thing effectively forbidding ranges, sets, and abstract numbers which don't result in a specific answer.   Unfortunately since simple math is only a small percentage of the complete set of math operations, we would be remiss to assume... right?  Even TRUE or FALSE could be as valid a return as any number.
Clearly even the simplest requirement needs deeper understanding and could be implemented in more than one, and only one way.  But let's make the leap. Let’s assume we know what it means to add two numbers and return the result. We still have a variety of unstated requirements to deal with;

How are the numbers provided?
What about errors and exceptions?
Do we maintain state between sessions?
Can a result be used as an input later?

What about the quality attributes?  Is it secure per session, per user, per role, or organization?  How about performance and scale?  Will this be done one addition at a time by a user or hundreds of times per minute by another block of code?  Is it limited to direct users input, if so, how many concurrent users does it need to support?

JUST WHEN IS IT GOOD ENOUGH?

Our customers and the industry suffer from this seemingly simple question. For some it’s never good enough. They dig and they plan, and test, and retry, never quite finishing … and never releasing a product. To others it’s always good enough. Work is released constantly, sometimes great, sometimes good, and occasionally useless. It’s left up to the consumer to decide if they should use it.

There are some, the professionals, who strive for and more often than not achieve a balance. They hold back when necessary, dig for details as required and release valuable, useful, usable products knowing they aren’t perfect. For me, it’s not just engineering. Software development is engineering, art, craftsmanship, diplomacy, and philosophy. The result may be quantifiable, but, like ‘good enough’ the process isn’t.