Reducing Communication Costs. A prerequisite for a successful reuse and integration is to communicate the intented purpose of the component, which problem it solves, when and how it is applicable. Here, to communicate means, to make known how to apply the component correctly and efficiently (Webster). The sender is the maker, the ``abstractor'', the receivers are the countable number n of users, the ``elaborators''.,
How can we reduce the time necessary to understand how to reuse a component? If the overall time it takes all n elaborators to figure out the reusable component - is an significant issue, this question must be seriously considered.
The Usual Communication Mechanisms are tutorials, reference manuals, source code comments, - and of course, verbal explanation and advice. Clear structuring of documents is a classical requirement. Very helpful are well organized on-line documentation systems with search capabilities on indexes and full text. Electronic access is inexpensive (to use and to update), concurrently available to many people and places, and very rapid for searching.
The abstact communicated information is - to a certain extent - always prone to be out-of-date, wrong, or incomplete (to a particularly larger extent if we want/need to share already early, non-perfect versions). Furthermore, this communication involves the process of encoding of a fact using natural language, which often leaves space for more than one unique interpretation (special programming languages exist for this reason).
In cases where these ambiguities become obvious, one can clarify them, e.g. by asking an expert (if available). Misinterpretations are the worst case. Typically, they are very costly and can render huge amounts of time and money useless.
Make Known by Exploration. The direct exploration of the object is a further mechanism of communicating the component's intention, its constraints, and usage. This trial-and-error procedure is a fundamental form of learning, it can be unsupervised or guided by some teacher. Despite its effectiveness, and probably due to its playful appearance, exploration is usually not perceived as a serious and canonical communication mechanism by its own.
The efficiency of exploration depends on the costs and benefits of each trial and possible errors. This has several constituents: Usually, primary test cost factors are the time to set up a test program (or better interactive test suite), the time to perform, and to evaluate the tests (including all needed compile-link-load-run loops; not to forget the recommended clean-up of possible temporary hacks). The potential error costs depend on the system fault tolerance, the time and effort to recover, and the real costs (ranging from a graceful fault signal, an abort, an irrecoverable system error, to a robot going wild). The benefit of an occured error is the information gained from the system (learn value) and depends on how informative the error messages are and how understandable the response is to the tester (e.g. ``#0042'' versus what-why-where). Of course, the benefit of a successful test is, beside the gained experience, the verification of the tested component's properties.
This analysis emphasizes the extra value of easily available, rapidly operating, user- and reuser-friendly experimentation frameworks. Asking the component itself, to explore and also to clarify any other ambiguity becomes than inexpensive.