#0130: Reuse: canned answers, sensible defaults, and rolling your own
Braingasm
The topic of reuse comes up a lot in software circles. Much of the conversation is about software reuse is in the form of reusable libraries and frameworks and the like. But, reuse goes down to the lowest levels of any system, and even into the hardware and beyond.
There are, however, other types of reuse. I think it’s possible to argue that some of these different forms of reuse can be at least as powerful as software reuse in their ability to enable the velocity of engineering teams, and perhaps other types of teams as well.
When I think about reuse, I use a simple framework to help me reason about what is going on. It goes like this:
- Canned answers: a canned answer is, as the name suggests, a ready-to-go asset that can be reused as-is. When you think about software reuse, this generally means that the reusable component exists and a programmer can get access to it and start using it right away. It might need some configuration, customisation, or installation of some kind. Still, for the most part, the component responds to a genuinely identified friction (ie a real problem that some group of potential users has in the real world), and there is a working implementation in software to use. A typical front-end UI framework like React or a back-end framework like Erlang’s (and Elixir’s) OTP are examples of canned answers to problems. There are others at different levels of granularity, and depending on how you think about it. An operating system is perhaps the coarsest form of software reuse that most engineers deal with daily. At the other end of the spectrum, a regular expression to parse email addresses might be a straightforward, self-contained, canned answer to a common software problem.
- Sensible defaults: a sensible default (or set of sensible defaults) exists when you have some ideas about the general type of problem to be solved, but there are still many uncertainties or extra work required to get a solution working. An example of this kind of thing might be a playbook for a machine learning pipeline that described an architecture and some cloud patterns that might be helpful. Still, when reusing sensible defaults, a software engineer is much more likely to be inspired by the asset and to use it as a starting point to build upon, rather than as a reusable piece of software. Here is an excellent example of just such a playbook for Ai and deep learning.
- Roll-your-own: the roll-your-own type of reuse is kind of like anti-reuse. The idea is that rather than reuse something that already exists, you go it alone and build something from scratch. You might think “that’s not reuse!” and you’d be right. It’s the literal opposite of reuse. The trick with the roll-your-own archetype are the obligations that you attach to it. If a team wants to roll-their-own for some components of their system, then that is fine, with one catch. They are obliged to take the result of rolling their own and do one of two things. Either use their successful efforts as inputs to document a new set of sensible defaults for the problem solved, or use their experience of failure (if the effort fails) to write up a “never ever do this again” document that captures the learnings of what went wrong. These learnings can then feedback into your database of sensible defaults.
These three categories of reuse (or anti-reuse) can be applied to behaviours as easily as they can be applied to software. In many ways, behavioural reuse can be at least as powerful as software reuse because you can make use of it much earlier in the product development lifecycle. An example of a canned answer for behaviour might be a recipe, whereas an example of sensible defaults for behaviour might be a code of conduct. The entire field of “antipatterns” would be a great example of a combination of sensible defaults and the learnings from roll-your-own activities that might not have been that successful.
Regards,
M@
[ED: If you’d like to sign up for this content as an email, click here to join the mailing list.]
