←back to thread

873 points belter | 1 comments | | HN request time: 0.442s | source
Show context
daxfohl ◴[] No.42951433[source]

Abstractions are a failure in most libraries too. Invariably something will come up that breaks the abstraction. Either new instances come up that don't quite match, or clients want new functionality that doesn't apply to all instances, or whatever.

I've come to the conclusion that in almost all cases, you should avoid providing any abstraction from your own library / service, and let consumers figure out what abstraction makes sense in their domain. By stipulating the abstraction, you're robbing your consumers of the ability to make things work the way they want, and painting your own thing into a corner.

When you build the abstraction, it seems like you're doing your consumers a favor. But that favor is short lived as the abstraction changes and breaks your consumers.

replies(2): >>42951811 #>>42954168 #
1. daxfohl ◴[] No.42951811[source]

Half of my team's work right now is changing our abstractions because a couple clients want something slightly different, without breaking existing clients. The other half of my team's work is KLO forced on us by our dependencies needing to change their own abstractions.

> When you build the abstraction, it seems like you're doing your consumers a favor.

"The road to hell is paved with good intentions."