Can we make it more generic?
I remember many horrible mistakes. I think we can learn a lot from one that looked innocent at the beginning and then turned into a monster.
We had a small function:
It searched through the event log, looked for “error” events and then it was looking for “error fixed” events. If it could not find one, we returned the event as an unfixed error.
One day we decided that we must make it more generic, because someone may need to use it for different purposes. After all, it was an event log. You can store anything you want, not only errors.
Because of that, we changed the friendly name of the function to:
1 2 3 getEventsOfTypeWithoutSubsequentEventsOfAnotherType( eventType: String, anotherEventType: String )
First of all, I have to apologize. I am sorry for creating such an abomination. It is wrong on so many levels.
The name is extremely long. I used to write very long names. A few years ago, when I was still using Windows XP, I learned about the path length limit because of a long class name. I hit the Windows XP path length limit… repeatedly.
The second problem is the fact that the function is “stringly-typed.” Event types are just strings. If you want to know why I think it is a horrible idea, read this blog post.
By changing the function name, we increased cognitive overload. We wanted to make it so generic that we diluted the meaning. It used to be easy to read and understand. The new name of the function makes you think. There is nothing wrong with calling a function “get unfixed errors” if you use it only for that purpose.
We exposed the implementation details in a righteous attempt to increase code reuse. Nobody needs to know if we store errors as events. The sad fact is that we use this function only to find unfixed errors. We don’t even care about other types of events.
Who wanted the generic version of this function? Nobody! Nobody cares whether the function looks for events without subsequent events of another type. People wanted to use it only to find unfixed errors.
Let’s face reality. We write generic code to look cool. Abstractions are tools. We like creating tools. We like it because people like us use our tools. Other programmers may appreciate your cleverness. The users never do it. They admire the work done by UX designers.
We, the programmers, need to focus on solving the problems we have, not the problem we wish we had. We must not create needless abstractions only because we think they may be useful one day or because we want to brag about the cool library we wrote.
Did you enjoy reading this article?
Would you like to learn more about software craft in data engineering and MLOps?
Subscribe to the newsletter or add this blog to your RSS reader (does anyone still use them?) to get a notification when I publish a new essay!
You may also like
- Data/MLOps engineer by day
- DevRel/copywriter by night
- Python and data engineering trainer
- Conference speaker
- Contributed a chapter to the book "97 Things Every Data Engineer Should Know"
- Twitter: @mikulskibartosz