In creating system models, design, or code, you must fight [[Documentation Rot]] and component decay. One of the many benefits of [[Modularity|modular]] design is that individual components of the body of work (be they model views, Confluence pages, function design specs, etc) can be worked on and matured independently. In so doing you are able to progress the maturity and design of the _overall system_ incrementally through the maturation of its pieces. **However**, when it becomes less easy to identify, scan, & parse the whole of "the system",[^1] it becomes more and more difficult to maintain fresh and valid documentation. Components in one area of the system may be incredibly mature, while other's you've lost track of have not been maintained and may represent old designs or ways of thinking. A monolithic package[^2] is much easier to scan over to ensure validity & consistency. Modeling tools can help with [[Referential Integrity]] and other such concerns, but most that I have experience with to a poor job of managing whether an element contained is is simply a stub or whether it has been iterated upon and is at a mature state. # Avoiding Rot - One approach that could combat this is the publishing of packed "versions" of your product that includes **all content contained by the system** (or, perhaps, just _excludes_ that which is not ready for the limelight) This represents a hand-selected and [[Automatically Tracked, Manually Confirmed|manually confirmed]] [[Distillation]] of the system. This does **not** prevent rot in the system as a _whole_, but does produce discrete products that could be rot-free. - You could imagine a system that included tools for traceability & lifecycle/maturity management. You could have an automated routine for any given component that rated how mature it was as a function of how mature its dependencies are. This is essentially how manufacturability works. > [!example] > When designing puzzle boxes, I'll write down how certain aspects "might" work, then much later actually _implement_ the aspects. Often when I return to the documentation I wrote I find that what it says is all wrong. **** ## Source - self ## Related [^1]: i.e. every single piece of content that comprises the totality of the design [^2]: e.g. a thesis or essay, as opposed to series of independent [[Atomic Notes]]