Why a Working Module Is Not Always a Good One
You can build a module that works today and still cannot use tomorrow. It taught the class, it got the laugh, it shipped the email, and then it sat in a folder and quietly refused to be reused, because it was built for one occasion and fused to it. Chapter 5 was about how to combine chunks into a module. This chapter is about a different question: once you have one, how do you know it is good?
Good, here, has a specific meaning. A good module is one you can trust to be reused, promoted, repackaged, and swapped without falling apart. That trust is what lets you stop rebuilding, so it is worth being able to judge. Four qualities separate a module that travels from one that is stuck where it was born. Learn to see them and you can look at any assembly and tell, fairly quickly, whether it is an asset or just a thing you happened to make once.
A module works when it does its job today. It is good when it can travel tomorrow.
Clean Boundaries
The first quality is clean boundaries. A good module has an obvious edge. You can say where it starts and where it stops, and everything inside the edge belongs to one assembly while everything outside it does not.
Boundaries sound abstract until you meet a module that lacks them. Picture a lesson that opens by finishing a thought from the previous lesson, wanders into material that really belongs to the next one, and trails off without a clear close. Where does it begin? Where does it end? You cannot lift it out cleanly because it has no clean edges to grip. A module with sharp boundaries, by contrast, can be picked up whole. The compound-interest lesson should start at compound interest and end when that idea has landed, with nothing bleeding in from the lessons on either side. The cleaner the edge, the more confidently you can move the piece, and moving pieces is the entire point.
One Complete Job
The second quality you already met as a building principle in the last chapter; here it returns as a test. A good module does one job, and it does the whole of it.
Both halves matter. One job means the module is not secretly two things wearing one title. If your lesson teaches compound interest and also argues for a particular investment product, it is two modules pretending to be one, and you will not be able to reuse the compounding half without dragging the sales pitch along. The whole of it means the module does not stop halfway. A lesson that defines compound interest but never makes the learner feel it has done only a fraction of its job; it will disappoint every place you try to use it. The test is simple to apply. State the module’s one job in a sentence, then ask two things: is there anything in here that serves a different job, and is the stated job actually finished by the end? Good modules pass both. They are complete, and they are about one thing.
Voice Baked In
The third quality is easy to overlook and expensive to skip: your voice has to be inside the module, not added later.
This matters because of what is coming. In the next part of the book you will repackage modules into many forms, and in the part after that you will pull them across many projects. If voice lives only in the final polish you apply to each finished piece, then every package and every reuse needs that polish reapplied, and you are back to redoing work. If voice is baked into the module itself, it travels automatically. The lesson sounds like you whether it appears as a webinar, a handout, or a chapter, because the way it explains, the analogies it reaches for, the rhythm of it, are part of the module and not part of the wrapping. A chef’s signature is in the dish, not painted on the plate at the last second, which is why it survives being served in a dining room, a banquet hall, or a box. Build voice in once, and you never bolt it on again.
Self-contained A module that carries its own setup and leans on nothing around it, so it still works the moment you move it somewhere new.
Self-Containment Over Dependency
The fourth quality is the most important, because it is the one that most often decides whether a module can be reused at all. A good module is self-contained. It carries what it needs and does not lean on its surroundings.
This is the dependency trap, and it is subtle because dependencies feel natural while you are building. You are writing the investing lesson right after the budgeting lesson, so you write “building on what we just covered,” and it reads beautifully in that moment. But that one phrase has now chained the investing lesson to the budgeting lesson. Put it in a different course and it refers to something that is not there. A self-contained module makes no promises its new home cannot keep. It does not say “as we saw last week,” does not assume a particular audience knows a particular prior thing, does not depend on sitting in a specific slot. It brings its own setup.
The kitchen test makes this concrete: a dish that travels versus a dish that is stuck. Some dishes work only in the restaurant that invented them, because they depend on a special piece of equipment, a particular supplier, a plating only that kitchen can do. Other dishes travel; you can make them at home, serve them at a dinner party, scale them for a crowd, because everything they need is in the recipe. A self-contained module is a dish that travels. A dependent one is a dish stuck in its original kitchen, no matter how good it tastes there. When you find yourself writing a dependency, you usually have two choices: cut it, or pull the thing it depends on inside the module so the module carries its own ground.
The Diagnostic Checklist
Put the four qualities together, splitting one complete job into its two tests, and you have a five-line way to vet any module before you trust it. Call it the travel test. Run a new assembly against these, and you will know in under a minute whether you have built an asset or a one-off.
- One job: can you state what this module is for in a single sentence, with nothing in it serving a different job?
- Complete: does it actually finish that job, with no missing middle?
- Clean boundaries: can you see exactly where it starts and stops, and lift it out without tearing anything attached to it?
- Voice in, not on: would it still sound like you if you delivered it in a completely different format?
- Self-contained: does it make any promise, reference, or assumption that its current surroundings happen to satisfy but a new home might not?
A module that passes all five is one you can keep with confidence. One that fails a line is not worthless; it is just telling you what to fix before you file it. Most failures are cheap to repair in the moment and ruinous to discover later, when you have dropped the module into something new and it quietly breaks. The checklist is how you catch them while the module is still in your hands.
A failed line is not a verdict; it is an instruction.
A failed line is not a verdict; it is an instruction. A blurry boundary tells you to trim the opening or close until the edge shows. Two jobs tell you to split it in two. A missing middle tells you to add the step that lets the outcome land. Voice that lives only in the wrapper tells you to rewrite the core until it sounds like you before any package goes on. A dependency tells you to cut the reference or pull the setup inside.
This same checklist works on the modules that are not content, too. A way you handle a hard conversation, a rule you use to make a decision: ask whether it does one job, finishes it, has clean edges, sounds like you, and stands on its own. The anatomy does not care what the module is made of.
What Comes Next
You can now build a module and judge whether it is good: one complete job, clean boundaries, voice baked in, and self-contained enough to travel. Those are the marks of an assembly you can trust to reuse.
A question is sitting underneath all of this, though, and the next chapter takes it head on. Not every combination should become a kept module. Some are worth building into recipes; some are meals you really should just eat once and forget. Turn everything into a module and you drown in a cluttered library; turn nothing into one and you are back to rebuilding forever. So next we look at the threshold: how to tell when a combination has earned the effort of being kept, and when you are modularizing something that never needed it.