YAGNI or do you?

You likely know the YAGNI principle in programming. The acronym stands for "you ain't gonna need it." It advises implementing only what is needed now, avoiding attempts to make current code account for potential, future features or use cases nobody has requested. It's the minimalist software development lifestyle.

I find this principle valuable. Therefore, I strive to adhere closely to YAGNI. It has saved me countless times from creating overly complicated solutions based on vague, imagined use cases. I say "strive" because the temptation to predict the future and save future time by working now remains strong.

When I first encountered YAGNI about 15 years ago, I became excited—as often happens with new concepts. Over time, I grew more proficient in applying it. Having experienced programming before and after embracing YAGNI, I can attest to its significant positive impact on my work.

Yet, one situation warrants relaxing strict adherence to YAGNI:

Collect more data—especially metadata—when gathering information, even if not immediately needed. You cannot magically recover data never collected. At least not easily; sometimes it's impossible.

For nearly every data record I plan to collect, I add metadata. My standard candidates: created_at, updated_at, version, created_by, though rarely needed immediately. Other attributes—not just metadata—might also be stored preemptively.

Strict YAGNI adherence makes sense for code; you can change it anytime when needs arise. Data, however, is far harder or impossible to retrieve later. Imagine realizing later that past data sets should include created_at timestamps: you cannot.

The Datensparsamkeit principle—collecting only the minimum data required—seems opposed to my relaxed YAGNI approach for data collection. This isn't contradictory because Datensparsamkeit addresses privacy and personally identifiable information.

Perhaps I contradict myself. Loosening YAGNI's strictness remains a sharp knife best handled with care.

My heuristic:

Back