Maintaining, Versioning, and Refining Modules

A Library Is Kept, Not Just Built

A library left alone does not stay valuable; it slowly decays. Figures age, approaches get overtaken, and even your best modules can always be sharper. The compounding you were promised in the last chapter is not automatic. It depends on tending what you have banked, so that the library stays current, keeps improving, and does not silently fill with pieces that no longer hold. Maintenance is the unglamorous price of the leverage, and it is small compared to what it protects, because tending a module you already have is far cheaper than rebuilding work you let rot.

There are four kinds of tending, and this chapter takes them in turn: refining a module so it gets better, versioning it when it needs to become two, retiring it when it no longer serves, and refactoring the library as it grows. None is difficult. Together they are what keep an inventory alive over years instead of letting it quietly turn into an archive of stale pieces. In a line: refine what can get better, version what has forked, retire what no longer holds, and refactor what has grown messy. Some maintenance is forced by a change, some happens on a periodic pass, and the modules that carry the most weight deserve tending first.

Refining: The Module Is Never Done

The first and most rewarding kind of tending is refinement. A module is never finished; it is only as good as the last time you improved it, and it can always get better. A module can be ready to use without being done improving. Every time you deliver a module and notice a sharper example, a cleaner explanation, a line that lands harder, you have a chance to improve the module itself, not just this one use of it.

The reason refinement is so powerful here is the inheritance principle from Part III, now operating across your whole body of work. Because every package and every project draws from the one source module, an improvement made to the source flows everywhere the module appears. Sharpen the compound-interest lesson once and the talk, the article, the course, and every future use all inherit the sharper version. This is the opposite of how unmaintained work behaves, where improving one piece does nothing for the others and everything slowly drifts. With a single source of truth, refinement compounds: every hour you spend improving a module pays out across every place it will ever appear, including places that do not exist yet.

The discipline is simply to put the improvement back into the source. When you find the better example mid-talk, it is tempting to use it once and move on. The habit that compounds is to return it to the module, so the gain is captured and inherited rather than lost. A recipe refined over years becomes something no single sitting could have produced; a comedian’s bit, tightened over hundreds of nights, becomes far better than the night it was written. Your modules can accrue quality the same way, but only if each improvement goes home to the source.

Versioning: When One Module Becomes Two

Sometimes a module does not need improving; it needs splitting. This is versioning, and it is distinct from the two moves it is easily confused with. Repackaging keeps one module and changes its form. Swapping replaces a piece. Versioning is different: it takes one module and makes it into two genuinely separate modules, because the single module was trying to be two things.

The signal is specific and worth learning to recognize. You want to change the lesson itself for one use but not another. As long as you are only changing framing, examples, or format, you are repackaging, and one module with many packages is correct. But the moment you find that one context needs the actual substance to be different, a deeper version for experts and a simpler true-but-different version for beginners, say, you no longer have one module wearing two outfits. You have two modules, and pretending they are one will tangle you, because every improvement to one will be wrong for the other. So you version: split the single module into two clean, separate modules, each doing its own job, each maintained on its own from then on.

Version sparingly, though, because every split doubles maintenance. Two modules are two things to refine, retire, and keep current. So do not version for differences that are really just packaging; reserve it for genuine forks in the lesson itself. The test is the one from the repackaging chapters, run in reverse: if holding the lesson fixed and flexing only the package can serve both needs, keep one module. Only when the lesson itself must diverge do you split.

Retiring: The Courage to Let Go

The third kind of tending is retirement, and it is the one people resist most, because it means removing something they built. But an inventory is only valuable if what is in it still holds, and some modules eventually stop holding. The field moves past an approach. A topic stops being relevant to your work. A module is superseded by a better one you have since built. When a module no longer serves, the right move is to retire it, pulling it out of the active library.

Retiring protects the very thing that makes the library useful: retrieval. Every dead module you leave in the inventory is one more thing to search past, one more near-match that surfaces when you are looking for the live version, one more small tax on every future search. Keeping outdated modules out of misplaced loyalty slowly turns your lean inventory back into the bloated archive you were warned against. So retire with some discipline. You need not delete the past, you can set a retired module aside if you like, but it should leave the working inventory so the active library stays current and fast. Retiring a lesson the field has outgrown is not losing work; it is keeping the library trustworthy.

Refactoring as the Library Grows

The last kind of tending appears only once the library is large: refactoring, reorganizing the modules themselves as patterns emerge. Over time you will notice the same sub-piece living inside several modules, or a module that has quietly grown to do too much, or a set of nested modules that no longer sit cleanly. Refactoring is cleaning that up, the way you would tidy a workshop that has accumulated.

Two moves cover most of it. When you find the same chunk or sub-module repeated inside several larger modules, extract it into its own module and have the others draw from it, so there is one source of that piece instead of many copies, the single-source principle applied inside the library. And when a module has grown overloaded, doing two or three jobs because you kept adding to it, split it back into clean single-job modules. Refactoring is not busywork; it is what keeps a growing library from collapsing under its own size, preserving the clean boundaries that made everything reusable in the first place. A small library rarely needs it. A large one needs it periodically, or the very abundance that makes it valuable starts to make it unnavigable.

Worked: One Module Over Time

See all four on a single module. You build the compound-interest lesson and bank it. Over a year of use you refine it, swapping in a better example you discovered mid-talk and returning it to the source, so every project inherits the upgrade. Then you notice a fork: advanced audiences need a substantively deeper treatment that would only confuse beginners, a difference in the lesson, not the package. So you version, splitting it into a foundational module and an advanced one, each now maintained on its own. A year later, a tax change makes one old savings-vehicle module teach the wrong thing, and no refinement will save it, so you retire it from the active library. And as your money modules multiply, you notice the same inflation explanation sitting inside three of them, so you refactor, extracting it into its own module the three now share. Same library, kept alive: refined, versioned, pruned, and reorganized, so that years in, it is sharper and leaner than the day you started rather than a drift of aging pieces.

What Comes Next

A library is kept, not just built. You refine modules so improvements inherit everywhere, version when a lesson genuinely forks in two, retire what no longer holds so the inventory stays trustworthy, and refactor as the library grows so abundance does not become clutter. Tended this way, the library compounds for years.

So far every module has been something you operate by hand, you pull it, place it, deliver it. But some modules quietly cross a line into doing work for you, a checklist that runs a process, a template that shapes the next thing automatically, a saved procedure you invoke rather than perform. When a module starts doing the work instead of just holding the content, it has become a tool, and that is the doorway to the final book. The next chapter walks up to that door.