What does it mean that inheritance in hierarchies?

Child items often inherit properties from their parent — be aware of what propagates.

Example: Your team operates under a company-wide policy: all meetings require an agenda circulated 24 hours in advance. Nobody on your team decided this. Nobody on your team voted on it. But every team member follows it, because the team is nested inside the organization, and the policy propagates downward. This is inheritance — a property defined at a higher level in the hierarchy automatically applies to everything below it. Now suppose your team also inherits the company's default project management methodology. But your team builds experimental prototypes, not production software. The inherited methodology creates friction because it was designed for a different context. The property propagated, but it should not have. Inheritance gave you something useful (the meeting policy) and something harmful (the wrong methodology) through the same mechanism. The mechanism does not distinguish. You must.

Try this: Choose a hierarchy you operate within — your organization, your note-taking system, your file structure, or your belief system. Identify three properties that propagate from a higher level to a lower level. For each one, answer: (1) Is this property explicitly stated or implicitly assumed? (2) Does it serve the child level well, or does it create friction? (3) If you removed the parent, would you independently choose this property at the child level? Any property where the answer to question 3 is 'no' is an inheritance candidate for override — which you will learn to handle in L-0273.