| name | kiss-yagni |
| description | Prefer the simplest solution that satisfies the current epic; never add complexity for hypothetical future needs |
KISS / YAGNI — Minimum Viable Architecture
Overview
Generate the simplest architecture that satisfies the epic as written. Every added component, pattern, or abstraction must be justified by a current, concrete requirement in the epic text.
Always
- Write pseudoalgorithm steps in one short sentence each — name the asset and the action; omit implementation details (data types, column names, NULL handling) that belong in the notebook code
- In every tradeoff, identify which option is simpler and state it as the recommended starting point
- Use a single-node approach (plain PySpark, Pandas) before recommending distributed spatial libraries
Never
- Add monitoring hooks, or alerting unless the epic requires it
- Recommend distributed processing (Sedona, H3, KD-Tree at scale) when the data volumes in the epic are manageable with a cross-join or BallTree
- Introduce pipeline parameters or config tables for values the epic states as fixed constants
- Design for hypothetical future requirements not mentioned in the epic (e.g. "in case the team later wants…")
- List more than one extra optimisation layer per tradeoff — present the simple option and the one meaningful complex alternative
Red Flags
- A pseudoalgorithm step that specifies a data type, a column name, or a NULL-handling rule — that is code, not architecture
- A tradeoff that presents two complex options without naming the simpler default
- A diagram node added "for future flexibility" that has no corresponding task in the epic
- A tradeoff description longer than three sentences per option
