Invest in Design

Treat design as part of ordinary delivery. Consider how the requirement should fit the affected responsibility before committing to the first working patch, then make only the bounded improvement justified by the current requirement, callers, constraints, and task authority.

Decision rule

During a feature or fix, invest enough design effort to reduce the demonstrated understanding and change burden in the affected responsibility while preserving required behavior and staying inside the approved task. A clean local patch may already satisfy the rule.

Design consideration does not wait for existing duplication or a completed bad patch. Structural edits do require current evidence and authority: the requirement, affected callers, constraints, or proposed implementation must show why the change improves today's design. A preference for cleaner architecture, nearby legacy debt, or possible future functionality is insufficient.

Apply the rule

1. Frame today's responsibility. State the required behavior, the code that owns it, the direct callers, and the guarantees that must remain stable, including relevant ordering, failure, lifecycle, and performance obligations.
2. Consider the coherent fit. Compare the clean local patch with the smallest design improvement that helps the current use. The investment may clarify a contract, documentation, name, state model, dependency direction, or responsibility; it need not create an abstraction.
3. Establish evidence and authority. Trace any structural edit to the current requirement, callers, constraints, tests, or proposed diff. Keep it within approved paths, contracts, dependencies, ownership, and pull-request grouping. Better design is not scope authority.
4. Make one bounded improvement. Change only the affected responsibility and direct integration needed for the behavior. A somewhat-general interface on first use is justified when it makes today's implementation or callers simpler; predicted adapters, registries, hooks, configuration, or other future functionality are not.
5. Verify behavior and total burden. Recheck the observable feature or fix, then compare caller-plus-implementation knowledge and change cost before and after. Include guarantees, sequencing, failures, recovery, and relevant performance constraints. One central owner, fewer branches, or fewer duplicate lines is not proof by itself.
6. State the honest result. Identify the demonstrated burden reduced or eliminated, the responsibility changed, and any residual limitation or legacy debt. Do not claim complete cleanup when the improvement is partial, and do not introduce avoidable new debt merely because older debt remains.