When a Combination Becomes a Module

Not Everything Deserves to Be Kept

By now you can build a clean module and judge whether it is good. That raises a question that sounds simple and is not: should you build it at all? Every combination you make could in principle be turned into a kept, reusable module. But turning all of them into modules is a mistake, and so is turning none of them. This chapter is about the judgment in between, knowing which combinations have earned the effort of being kept.

The reason this matters is that keeping is not free. A module you decide to keep has to be stored somewhere you can find it, named so you recognize it later, and maintained as the world around it changes. That is a real cost, paid quietly over time. So the question is never “could this be a module” - almost anything could. The question is “is this combination worth that ongoing cost,” and that has a real answer. A combination is an assembly you made for the job in front of you; a module is a combination you have decided is worth keeping.

The Threshold: Recurrence and Foreseeable Reuse

A combination crosses the line into module when it will be used again. That is the whole test, and it has two forms.

The first is recurrence you have already seen. You built this combination once, and then you found yourself building something very like it again. The lesson on compound interest is not a guess about the future; you have taught that idea, in roughly that shape, to every cohort you have ever had. It recurs. A combination that has already come back two or three times is announcing what it is. The first time may be a one-off, the second a signal, the third evidence. It is not a one-off; it is a module you keep accidentally rebuilding, and the only question is whether you will keep rebuilding it or keep it on purpose.

The second form is foreseeable reuse you can reasonably predict even before it recurs. Sometimes you build something and know, while you are building it, that you will want it again, because it answers a need that is obviously going to return. You do not need three repetitions to see it. But be honest with yourself about the difference between “I can clearly see this returning” and “I might use this someday.” The first is a real signal. The second is the wish that fills libraries with modules nobody ever opens again.

Let It Prove Itself

This points to the cleanest rule in the chapter: when in doubt, let the combination prove itself before you promote it to a kept module.

There is a failure mode where people, newly excited about modularity, try to turn everything they make into a polished, reusable, carefully filed module on first creation. It feels productive and it is mostly waste, because you are paying the full cost of keeping for combinations that may never come back. Worse, you are guessing at the reusable shape before you have any evidence of how it actually gets reused, so you tend to guess wrong and build the wrong boundaries.

A comedian shows the healthier pattern. A comedian does not enshrine every funny thing said on stage. Most nights produce a riff, a one-off line that lands in the moment and is gone. The comedian lets the material run. The line that keeps landing, night after night, room after room, earns its place; it gets tightened, kept, and folded into the act as a reliable bit. The threshold is not “was it funny once.” It is “does it keep working.” You can afford to be the same way. Build the combination for the job in front of you. If it comes back, that is your signal to lift it out, clean it up to the standard of the last chapter, and keep it. Recurrence promotes a combination into a module. You do not have to decide on day one.

Too Few Modules: Rebuilding Forever

The two ways to get this wrong are worth naming directly, because they pull in opposite directions and you want to sit between them.

The first error is keeping too little. This is the default most people start from, and it is the whole problem the book opened with. If you treat every combination as a meal to be eaten once, you keep nothing, and you rebuild the recurring pieces over and over. The compound-interest lesson gets reconstructed every term. The reliable bit gets rewritten every tour. You pay the rebuilding tax indefinitely because you never let any combination graduate into something kept. If your instinct is to under-keep, the fix is the recurrence rule: the moment you notice you are building something for the second or third time, stop and make it a module. That one piece of self-observation, catching the second rebuild, is where most of the savings in this book actually come from.

Too Many Modules: Clutter

The opposite error is keeping too much, and it is the trap of the recently converted. If everything becomes a kept module, your library fills with assemblies you will never reach for, and the cost lands in two places. It lands in maintenance, because every kept module is something you have implicitly promised to keep current, and a library of a thousand modules is a thousand small obligations. And it lands in retrieval, which is the quieter killer. The entire value of a module is being able to find the right one fast when you need it. Bury the twenty modules you actually reuse inside three hundred you keep “just in case,” and you have not built an asset, you have built a haystack. Finding your good modules now costs enough that you may as well have rebuilt from scratch.

So more modules is not better. The right size of a library is “the recurring, reusable pieces, and not much else.” A lean collection of proven modules beats a sprawling collection of hopeful ones every time, because the lean one you can actually use.

A Practical Way to Decide

Put the judgment into a form you can apply in the moment. When you finish a combination and wonder whether to keep it, ask three things:

1. Have I built something like this before?
2. Can I clearly name a future occasion that will need it again?
3. Is its reassembly the expensive, decision-heavy kind from Chapter 1, rather than something trivial to redo?

Two or three yeses, and you keep it; clean it up and file it now while it is fresh. Mostly noes, and you let it go, trusting that if it turns out to recur, the recurrence itself will tell you, and you can promote it then.

Notice what this does to the anxiety of letting things go. You are not deciding, permanently, that a combination is worthless. You are deciding only that it has not yet proven it will recur. The door stays open. A combination you released can always be promoted later, the second time it comes around, because by then it will have earned it.

A Decision, Worked

Make this concrete with two combinations from the same week. A company hires you to run a one-time workshop, and you build a segment on the tax quirks of their particular benefits plan. It works well in the room. Should you keep it as a module? Run the three questions. Have you built something like it before? No. Can you name a future occasion that will need it again? Not really; it is specific to one employer’s plan. Is its reassembly expensive? Somewhat, but the recurrence is the missing piece. Mostly noes. So you let it go. If that company calls back next year, you will have it in the delivered workshop and can promote it then, when it has earned it.

That same week you build, for the same workshop, a short explanation of why starting to save early beats saving more later. Run the questions. Have you built this before? Constantly; it is a cousin of your compound-interest lesson. Will it recur? Almost certainly, in nearly everything you teach about money. Is rebuilding it expensive? Yes, it is the decision-heavy, get-the-example-right kind. Three yeses. So before you move on, you lift it out of the workshop, clean it to the standard of the last chapter, and file it. The workshop is over by Friday, but that module is now yours for good. Two combinations, one week, opposite verdicts, and the rule made the call for you in under a minute each.

What Comes Next

You can now decide which combinations to keep, holding the line between rebuilding forever and drowning in clutter, and letting recurrence make most of the decision for you. That keeps your stock of modules honest: proven, reusable, worth their upkeep.

So far, though, we have mostly talked about modules at one level, a lesson built from chunks, a bit built from jokes. But you saw in Part I that there is no ceiling. Modules combine into larger modules, which combine into larger ones still. The next chapter takes combining up the ladder: how to compose modules into bigger modules, how a finished whole gets promoted into a part of something larger, and the one discipline that keeps the whole stack from seizing up, keeping your nested modules independent enough that you can still pull any one of them back out.