Making anything unambiguous means finding a way for others to understand which gets us to the knotty problem of how we communicate the method we have taken to create unambiguousness. (probably not even close to being a real word).
Tom Cagley’s comment referred to the last few sentences of the “Hatin’ on Nulls” post:
Coherence and consistency should be considered hallmarks of an API. As Erik Dietrich noted in “Notes on Writing Discoverable Framework Code”, a good API should “make screwing up impossible”. Ambiguity makes screwing up very possible.
Ambiguity and uncertainty are facts of life. Architects must work with less than perfect certainty to resolve ambiguous concerns and design an optimal solution for the problem(s) at hand. An important goal in achieving that optimal design must be to create a design that is comprehensible to the user. The design communicates how to achieve the solution to a problem. In doing so, we must deal with the ambiguity and uncertainty so that our clients don’t have to.
This, in my opinion, is a key defense of the phrase “form follows function”. As Tom Graves’ post “Form follows non-function” pointed out, perception of what is “good” design depends on quality of service attributes (AKA non-functional requirements). The functional attributes are necessary, but far from sufficient.
Interfaces, whether aimed at humans or machines, should be comprehensible (APIs are first consumed by humans before they are consumed by applications). In both cases, a lack of clarity will make them hard to use. It doesn’t matter if the design is technically clever, if functionality is hard to discover, in many cases it may as well be absent. It’s certainly likely to be perceived that way.
If the customer can’t accomplish a desired function, they’re going to feel constrained. Constrained customers tend to be unhappy customers. Unhappy customers tend to convert to ex-customers