Designing for yourself versus for a public library

There is a big huge difference between 'well designed code' in case of an application and a public library..
Something I'm still struggling sometimes to keep in mind..

Story time

I was working on an abstraction over the database management library we use in an iOS app not that long ago. One of the requirements was for the client to be able to query for the updated_at column of an entity but without taking in consideration when the entity was updated because of a background sync with the back-end.

Now, you may be thinking to yourself "But that's an easy task! 🤨 Just don't update the timestamp when the entity is update by the sync" and you would be right. The question is though, how to achieve this?

A pretty straight forward solution would be to have a flag (in form of a parameter on the update method) that indicates whether the timestamp should be updated or not and this would work. In fact, this is the solution I ended up going with. But before that, I had to convince myself that I'm not building a library. That's because for me, such a flag seems to specific to my application.

So what other solutions are out there? Well, probably a lot, but let's take an example. My first idea was to introduce a new column, that stores information about who updated the entity. Something like user vs system. Unfortunately this may not be enough. In my case, I also had to know when was the entity updated the last time. So by simply ignoring the timestamp if the update was made by the system would not solve my issue.

This could lead to the next idea, which is to store the last two teimstamps and info about who updated. Which on its own introduces a lot of extra complexity. Maybe you forget to update the second one somewhere. Maybe that is also by the system so now you need 3 sets of columns. You see where I'm going? Going down this rabbit hole quickly leads to the development of a versioning or history tracking system which is a cool thing, can be interesting to implement but is 1000% overkill for what I needed.

Conclusion

As I've already hinted, I ended up going with the flag based solution. Why? Because it doesn't matter at all! It's not like I'm going to release this database wrapper I've built in a day and that's sole purpose is to hide the library we are using from the rest of the app. The point I'm trying to make is that as long as your code follows some sort of guildiles (like SOLID), you don't need to always think like a library developer. In fact, knowing when to act like so is a complete skill on it's own that you, as a software engineer, should learn as quickly as possible in order to save yourself tons of ours wasted on unneceserly overengineered code!