| 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 every last bit 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! |