There is an old and endlessly repeated saying in programming and software engineering: YAGNI – You ain't gonna need it. It is mainly related to premature optimization and over-engineering, things most developers are prone to. But sometimes, you should still follow your gut feelings.
Published on Fri, February 18, 2022
When I started designing that communication feature of the application I am currently working on, I had a constant voice telling me that I should keep things as simple as possible. The budget was tight both on money and time, as the project was entirely bootstrapped.
The feature itself, more or less a messenger, is simple and complex at the same time. Exchanging text messages isn't revolutionary, nor is it hard to implement a rough first version. But as people spend relevant parts of their lifetime in front of WhatsApp, Signal, Facebook Messenger, and whatever else, expectations are certainly higher than they were like 15 years ago when all we got was SMS.
So I wondered whether or not I should even bother to store the timestamp of messages being read by the system's users. Of course, there was no plan to show that timestamp anywhere, so it wasn't particularly useful then. But it wasn't hard to implement either, and something told me it could be more valuable in the future. So I sat down to spend a few additional hours on that little feature.
Fast-forward a few months, the first feedback from real system users comes in. And guess what, what feels odd to them is that they can't tell whether or not the recipients read their messages. It felt like they were shouting into a void. How come?
As with said messenger apps, we are used to receiving near-instant feedback. Think of those checkmarks in WhatsApp or Signal or the symbols used in Microsoft Teams. As the app is used in a business context, it might be even more relevant to know whether or not your message has been read.
Long story short, as I had already stored the timestamps right from the start, I was now able to build a neat little feature on top of it that represents the read status in the UI. If I hadn't had that data available, that would not have been the end of the world. But it would have felt wrong regarding those messages that lacked the read metadata.
Conclusion: while YAGNI might be a good and recommended heuristic for most situations, it's important to be able to make exceptions from the rule and follow your gut feelings. This is especially important in cases where you cannot simply revert your decision: Data that is not persisted today can never be used in the future (sometimes that is a good thing, of course ;-)).