April, 2025
YAGNI, or, You aren't gonna need it, is a standard piece of advice that warns against over engineering and building too many features too early. I think its great and saves you from wasting time, which can kill a project.
However, there's an exception that I call YAGRI, or, "You are gonna read it". It means that you shouldn't just store the minimum data required to satisfy the current product spec. You should also store data that you'll highly likely use (read), such as timestamps and contextual metadata.
This problem tends to happen when a UI design shows that you only need to display a few specific bits of data to the user, so you only store those exact fields in the database. You've satisfied the design and ship it. Then later you realize you're missing valuable information to help debug an issue, do internal analytics, etc.
As an example, this commonly occurs when implementing a feature to let users delete something. The easy way is to just delete the row from the database, and maybe that's all that the current UI design call for. In this situation, regardless of the requested feature set, as engineers we should maintain good data standards and store:
- who deleted it
- how they deleted it (with what permission)
- when
- why (surrounding context, if possible)
In general, these are some useful fields to store on almost any table:
- created_at
- updated_at
- deleted_at (soft deletes)
- created_by etc
- permission used during CRUD
This practice will pay off with just a single instance of your boss popping into a meeting and going "wait do we know why that thing was deleted, the customer is worried...".
However, not every one of these fields that you store will end up serving a purpose. But maybe just a single field on a single table will save you one day, and that makes up for the costs of implementing a dozen others. Most of the apps we build, at the end of the day, are about storing data to keep track of facts. It's quite possibly your most important job as an engineer to steward and maintain this data.
Of course you can go too far in the other direction. You shouldnt just log everything. But I've never heard someone complain about a table having too many timestamps.
