A good rule of thumb is to abstract inherent complexity and not incidental complexity.
Loggers are examples of incidental complexity. There is nothing fundamental about sending the warning by email vs slack vs irc. The way to deal with this is not to keep adding more and more options, because you end up with combinatorial growth in the number of interactions, it's to make it company policy that you only use email and discipline anyone who doesn't.
> There is nothing fundamental about sending the warning by email vs slack vs irc.
I agree with this but I would put it somewhat differently. To me, notifications are a separate service, and whatever options there are for notification should be orthogonal to whatever is doing the notifying. If company A's policy is that notifications only go by email, nothing else, while company B has email, slack, and irc, that's for their respective notification services to worry about, not for each individual application that is using the notification service. To the application, it should be send_notification(content, recipient) and that's it.
Have you considered the power in having little abstraction? There's a whole school of thought (the APL/J/k community) that thinks these kinds of abstractions are not just unnecessary, but actually harmful. After trying my hand at "abstractionless" programming in kdb+/q, I tend to agree. When your entire program is only a couple lines of code, you don't need to code for tomorrow. You don't need to think about the future. The code is so short you can just throw it away and start over.
And in fact, this is what Arthur Whitney (creator of kdb+/q and Shakti) does. Every new version of k is started entirely from scratch. No code reuse, no libraries, no sharing.
I'm delighted to learn about this perspective. Appreciate the note.
I believe in reusability with software engineering. The reason why legos is so much fun is because you can compose and build things out of simple shapes.
I also agree with you and others in terms of simplicity. I guess what I failed to communicate in the original post was about the judgment that is required to make the right decision, and that caused quite a bit of opposing arguments.
I believe that the right level of abstraction is required for any non-trivial system. Life is full of balancing act - like yin and yang. Too little abstraction is also costly and leads to code bloating and maintenance nightmare.
I understand it was a typo, and I generally think you did an ok job pointing out that over-abstraction has it's costs.
My real problem is that abstractions are Expensive with a capital E. That typo happened because you had to think harder, about more lines of code, for a longer time. You're spread thinner, and the amount of time you spend actually reading each bit goes down. It's easier for errors to slip in. It takes more time to reason about. And worst of all, most people are genuinely bad at coming up with good abstractions - It turns out it's really hard too.
Now - Once a problem has reached sufficient complexity - you need them. But they really should be avoided until you're AT that point.
Using an abstraction too early is overfitting to your current problem space.
To make a more genuine criticism than just pointing out the typo - What happens if it turns out that your next health check 'fetcher' needs to emit events, or requires a callback, or doesn't use a url but a redis connection string?
You haven't avoided the need to change "check()" in any of those cases.
The abstraction just leaked, and now you have to understand everylastbit of all that code again. Which is another chance for small errors to slip in, which they will do, because programmers are human and we fuck up ALL the time.
From my experience, the best way to avoid fucking up is to just not do anything you don't absolutely have to. Avoid adding lines, avoiding adding more things to understand, avoid adding complexity, avoid adding abstraction.
Do the job you need to do, and JUST that job. But hey, it turns out that's Boring!
Loggers are examples of incidental complexity. There is nothing fundamental about sending the warning by email vs slack vs irc. The way to deal with this is not to keep adding more and more options, because you end up with combinatorial growth in the number of interactions, it's to make it company policy that you only use email and discipline anyone who doesn't.