Designing for yourself versus for a public library
Don't over-engineer your apps! Save yourself some time
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 through 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 performed the update. 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!
Latest articles
Here are some more articles that may interest you. Check them out!

The RawRepresentable protocol
If you’ve ever used a Swift enum with a raw value, you may not even realise that you have already worked with the RawRepresentable protocol. But what is it and how can you make use of it? In this article we are going to investigate the RawRepresentable protocol and I’m going to show you some neat ways for using the protocol to our advantage.
Read more
Proportional layout with SwiftUI
Starting from iOS 16, SwiftUI gives us the option to build custom layouts that can control very precisely where each subview should be placed. We have the option to build layouts that can be used just as the VStack, HStack or any other built in Layout you may be familiar with from SwiftUI. This new tool creates an opportunity for us to really easily create layouts that size their subviews proportionally to its own dimensions, similar to flex box in CSS
Read moreThe @ and # symbols in Swift
When a new feature is introduced in a programming language, we as developers are often quick to assume it will solve many of their challenges. The excitement to experiment with such features is natural, but it’s often accompanied by the realisation that every solution brings its own set of unique challenges. This was no different when actors were introduced.
Read more