product requirement
Implicit, correctness, consistency and undefined behavior
When we design software/product, there are various product requirements the product is expected to meet. If these requirements are written and can (should) be translated into unit tests, they are explicit. In my experience, explicit requirement rarely cause friction between PM and engineer, and the back-and-forth are usually a result of implicit requirements that are not understood.
In my mind, a product is finished when it is "correct", in other word it passes all unit test and are ready to be deployed (or optimized for performance but in a separate topic). The only type of implicit requirement I would accept can be described as elementary/middle school level common sense, e.g. 1+1=2 in a calculator program. Anything else is in the "undefined" territory if not stated in the product requirement, aka "it doesn't matter" or "I don't care", and I feel engineer should have the liberty to define/change undefined behavior at will.
This leads to another topic, product behavior should be consistent, regardless of version or platform. While this statement is generally correct, it is never free. I will demonstrate in a simple example below:
While both method calls return the correct result, they are inconsistent. This can happen between platform or between version, even as a result of race condition, one tiny difference in a seemingly unimportant part of the software can have butterfly effect and alter the entire result, given its stochastic nature. So it goes back to the original question, what is the cost of maintaining consistency in multi-threaded/distributed computing/version control? Its hard to estimate, but as to my point, its not free.
One of my colleague once said, a good product requirement should allow any decent engineer (internal or external) to build the right product (without asking any additional question). Another of my colleague once said, there is a good understanding within the team in terms of implicit requirement, while having good team chemistry is always good, I think it shouldn't be the reason to simplify product requirement. Coming from a civil engineering background, I always compare building software against building building. Why does architect draw the wall while it is implicit that all buildings have wall.