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.

Table of Contents

No reason

We had a small function:

getUnfixedErrors()

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:

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.

No reason

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.

Can we make it more generic?

No reason

[JUG Thüringen] Effortless Domain-Driven Design - The real Power of Scala

The cake pattern is a lie

Can we make it more generic?

No reason

[JUG Thüringen] Effortless Domain-Driven Design - The real Power of Scala

The cake pattern is a lie

Related Posts

Query string validation in Fastify

Assert object pattern

A "known bug" is still a bug