Reusable Modules, and When to Hold Back

A module is almost always created too early. The scenario is constant: you need a second message queue, you notice the block looks like the first one, and you extract it into a module "for later." Six months on, the module has eleven boolean variables, three count = var.enable_x ? 1 : 0, and nobody dares touch it because it's called by four projects, two of which depend on behavior the third considers a bug. The abstraction that was supposed to reduce duplication has produced a component harder to read than the four copies it replaced.

The problem isn't modules; it's when you create them. A module is an interface, and an interface can only be designed properly after you've seen several real usages. Written after two or three deliberate duplications, it captures what really varies and what doesn't. Written at the first resemblance, it freezes an imaginary need and parameterizes the wrong things. This lesson shows how to write a useful module, then gives concrete criteria for deciding whether you should write one at all.