Lying Abstraction

Abstractions that lies to us, even if they lie a little bit.

This is one of the challenges of software is that what you write today and works as truthy abstractions to start out can become a lying gremlin in the future, that if not refactored away becomes the start of cognitive overload, where we are afraid to touch code at the fear that the house of cards will come crumbling down.

It's quite easy to fall trap to making such Gremlins when we look at use cases from one point of view and things appear to align. Let's take an example.

Let's say we have visit history implementation where we record the visit history for the user when they have visited particular files. In this example we added this feature later on and the users already have files in place. What we might think is ok we don't have their visit history for all files but we DO have files creation time, so let's add that creation timestamp as the first visit. That makes sense logically to us and we could put that in place, with other features taking implicit dependency that such starting visitation timestamp for previous all files exists. BUT such assumption, breaks when we have files that could have been created by multiple users, all of a sudden we have visitation timestamps shown to users of files that they have never heard off. Hence, the moral of the story is to VERY careful if you are making up assumptions that are not rooted in facts.