Styles of reuse: what do we expect from each other?

Reuse seems like a good idea. Building new stuff takes time and money, whereas copying or using existing stuff sounds like it should be easier. If that’s the case, though, why is it so hard? Plenty of organisations attempt to control the cost and complexity of their technology by increasing reuse, setting metrics to measure their achievement of this goal. Unfortunately, these metrics usually show that they have limited success: people seem to like building and acquiring new stuff, even if they have stuff that does the same job.

I think that one of the reasons for this phenomenon is that reuse is dependent on trust (if I am going to use your software, I need to trust that it works), trust is dependent on expectations (if we are going to work together, we need to know what we expect from each other), and expectations are often unstated or unclear (I don’t know what I can expect from you, and you haven’t said what you expect from me). Furthermore, there is more than one style of reuse, each of which comes with different expectations.

Let’s attempt to define some styles of reuse and the different expectations that they imply. We’ll start with the gentlest type of reuse and progress to the most assertive, and will use those familiar deuteragonists from technology examples: Alice and Bob.

Knowledge: Alice has solved a common problem and acquired valuable experience. Alice expects, if she takes the time to share her knowledge, Bob will listen. Bob expects that, if he takes the time to listen to Alice, he will learn something.

Principles: Bob has analyzed several approaches to the same problem, and abstracted some helpful rules to follow. Bob expects that, if he takes the trouble to define and agree these principles with Alice, that she will follow them. Alice expects that she gets a say in defining these principles and that, if she follows them, she will get better outcomes.

Standards: Alice has gone deeper and codified practical experience into some deeper technical standards. Alice expects that, if she does the work to agree and communicate these standards, that Bob will comply with them. Bob expects to participate in the definition, refinement and maintenance of the standards and that, if he complies with them, they will save him time and money.

Patterns: Bob has spotted that several people have solved the same problem in similar ways, and combined their solutions into a pattern. Bob expects that, if he spends the time creating this pattern and sharing it with Alice, that Alice will make use of it when she has the same problem. Alice expects that the pattern will provide a helpful and viable approach to solving a common problem.

Code: Alice has written some code which she believes to be useful, documented it and published it in a repository. She expects that Bob will look in the repository when he is contemplating building something new, and that he will contribute to her code. Bob expects that using the code will save some time - and that it will behave as documented.

Contracts: Bob has noticed that several people are using similar suppliers to do similar things. He has agreed with his colleagues that they should all use the same supplier for certain services, and has negotiated a contract with a bulk discount. Bob expects that Alice will use that contract as agreed. Alice expects that using this contract will save her time and money, and will give her better terms and conditions.

Solutions: Alice has developed a complete solution to a common problem: code, documentation, deployment scripts, tests and so on. She has agreed with potential users of the solution that she will define and maintain a reference implementation which they can follow. Alice expects that Bob will deploy the solution when appropriate, and will provide feedback on areas for improvement. Bob expects that the solution will work, and that Alice will maintain it.

Services: Bob has built a fully managed service with well documented behaviour accessible through APIs. Bob has agreed that others will use this service, along with the ways in which users will contribute to cost. He expects that his service will be used as agreed, and that users will pay. Alice expects that the service will perform to contract and that Bob will listen to feedback and will continue to improve it.

All of these forms of reuse are well established and none should be surprising. However, I think that it is common to get them mixed up, and to find that we have mismatched expectations. We might, for example, wonder why we are struggling to use a system as a fully defined solution, when the person offering it to us only meant to share some knowledge. Similarly, we might be surprised to find someone asking us to contribute to the development of their service, when we thought that they were just offering it as a pattern.

If we start by making our style of reuse explicit, as well as our expectations, we might be more successful - and do more to help each other.

(Views in this article are my own.)