Over on ReadingRavioli, RonJeffries explains how when code is highly decomposed, you pay less attention to the implementation details and more attention to algorithm itself:

	 :	When you get good at Smalltalk, you stop bothering to remember the code. You just go with the algorithm as stated, as if the programming language actually understood "is target at the middle of the range". In essence, it does!

But there's some sort of implicit trust, isn't there? I mean, there's a method in front of you that says ''isTargetAtMiddleOfRange'', but how do you know it's written well? Who wrote it? Did they mess it up? (Did you mess it up?)

I wonder what sort of factors might make code more trustworthy. Unit tests? Having smart co-workers? --francis
* This disturbs me, too, but I think the idea is that, most of the time, that doesn't come up, and to the extent that it does, the division of responsibility is more clear with this approach, so it's easier to figure out whether an implementation is meeting its contract.
* If the code is just plain not working at all, that would be a different matter, so unit tests figure in. And sure, if you have reason not to trust whoever wrote the implementation, then presumably nothing will be convincing other than vetting it.

''ProofOfCorrectness''
* A good thing, but not the final word -- similar questions arise about trusting someone else's proof, for instance.
----
See also ReflectionsOnTrustingTrust TrustButVerify TrustTheMetastructure